TEMA 12

5. ARQUITECTURA DE SERVICIOS WEB

(WS)

5.1. Introduccin
Desde mediado de la dcada de los 90, con la aparicin y extensin de Internet a
niveles jams pensados, ha existido siempre la necesidad de integracin entre
sistemas muy heterogneos, tanto software como hardware. Muchas empresas
comenzaron grandes proyectos para lograr la mejor tecnologa integradora de
sistemas, pero a medida que la competencia se hacia cada vez ms fuerte, la
integracin se hacia cada vez ms difcil.

Estas empresas pronto se percataron que la imposibilidad de crear una plataforma

integrada de forma individual; se hara necesario atacar el problema de raz,
buscando un lenguaje comn de intercambio de informacin aprovechando
los estndares existentes en el mercado. Bajo este contexto nacen los
Servicios Web basados en XML

5.2. Definicin

Un servicio Web (Web service) es una coleccin de protocolos y estndares que

sirven para intercambiar datos entre aplicaciones. La interoperabilidad se consigue
mediante la adopcin de estndares abiertos.

Estos servicios proporcionan mecanismos de comunicacin estndares entre

diferentes aplicaciones, que interactan entre s para presentar informacin
dinmica al usuario. Para proporcionar interoperabilidad y extensibilidad entre estas
aplicaciones, y que al mismo tiempo sea posible su combinacin para realizar
operaciones complejas, es necesaria una arquitectura de referencia estndar.

Distintas aplicaciones de software desarrolladas en lenguajes de programacin

diferentes y ejecutadas sobre cualquier plataforma pueden utilizar los servicios web
para intercambiar datos en redes como Internet.

Existen muchas otras definiciones alternativas, lo que muestra la complejidad a la

hora de concretar una adecuada descripcin que englobe todo lo que son e implican
los servicios web. A continuacin ofrecemos algunas:
 Conjunto de aplicaciones o de tecnologas con capacidad para interoperar en
la Web. Estas aplicaciones o tecnologas intercambian datos entre s con el
objetivo de ofrecer unos servicios. Los proveedores ofrecen sus servicios
como procedimientos remotos y los usuarios solicitan un servicio llamando a
estos procedimientos a travs de la Web.

Componentes software que permiten a los usuarios usar aplicaciones que

comparten datos con otros programas modulares, va Internet.

Aplicaciones independientes de la plataforma que pueden ser fcilmente

publicadas, localizadas e invocadas mediante protocolos web estndar, como
XML, SOAP, UDDI o WSDL. El objetivo final es la creacin de un directorio
online de servicios web que pueda ser localizado de un modo sencillo y que
tenga una alta fiabilidad.

Nueva generacin de aplicaciones que trabajan colaborativamente en las

cules el software esta distribuido en diferentes servidores.

Como podemos apreciar, probablemente existan tantas definiciones de los Servicios

Web como compaas que los desarrollan, pero casi todas las definiciones se
desarrollan sobre estos aspectos tcnicos comunes:

Los Servicios Web exponen funcionalidad til a los usuarios Web mediante
un protocolo Web estndar. En la mayora de casos, el protocolo utilizado es
Simple Object Access Protocol (SOAP).

Los Servicios Web proporcionan un modo de describir sus interfaces con

suficiente detalle para permitir a un usuario construir una aplicacin cliente
para comunicarse con ellos. Esta descripcin se proporciona generalmente
en un documento XML que responde al nombre de documento Servicios
web Description Language (WSDL).

Los Servicios Web se registran de modo que los potenciales usuarios puedan
encontrarlos. Esto se realiza mediante Universal Discovery Description
and Integration (UDDI).

Aunque la idea de la programacin modular no es nueva, el xito de esta tecnologa

reside en que se basa en estndares conocidos en los que ya se tiene una gran
confianza, como el XML. Adems, el uso de los servicios web aporta ventajas
significativas a las empresas. El principal objetivo que se logra, es la
interoperabilidad y la integracin. Mediante los servicios web, las empresas pueden
compartir servicios software con sus clientes, socios, proveedores, etc.

Esto ayudar a las compaas a escalar sus negocios, reduciendo el coste en

desarrollo y mantenimiento de software, y lanzando productos al mercado con
mayor rapidez. La integracin de aplicaciones har posible obtener la informacin
demandada en tiempo real, acelerando el proceso de toma de decisiones. La
evolucin de Internet hacia los servicios web, mejorar los resultados globales de
las empresas, reduciendo sus gastos y guindolas hacia una mejora progresiva de
la calidad. La adopcin de la tecnologa de servicios web por la industria puede
suponer el primer paso hacia una economa global.

5.3. Ventajas e Inconvenientes

Ventajas:

Aportan interoperabilidad entre aplicaciones de software

independientemente de sus propiedades o de las plataformas sobre las que
se instalen, permitiendo la interoperabilidad entre plataformas de distintos
fabricantes mediante protocolos estndar.

Los servicios web fomentan los estndares y protocolos basados en texto,

que hacen ms fcil acceder a su contenido y entender su funcionamiento.

Al apoyarse en HTTP, los servicios web pueden aprovechar los sistemas

cortafuegos sin necesidad de cambiar sus reglas de filtrado. La principal
razn para usar servicios Web es que se basan en HTTP sobre TCP en el
puerto 80. Dado que las organizaciones protegen sus redes mediante
cortafuegos (firewalls) que filtran y bloquean gran parte del trfico de
Internet, cierran casi todos los puertos TCP salvo el 80, que es,
precisamente, el que usan los navegadores. Los servicios Web se canalizan
por este puerto, por la simple razn de que no resultan bloqueados.

Permiten que servicios y software de diferentes compaas ubicadas en

diferentes lugares geogrficos puedan ser combinados fcilmente para
proveer servicios integrados.

Los servicios web son muy prcticos al aportar gran independencia entre la
aplicacin que usa el servicio web y el propio servicio. De esta forma, los
cambios a lo largo del tiempo en uno no deben afectar al otro. Esta
flexibilidad ser cada vez ms importante, dado que la tendencia a construir
grandes aplicaciones a partir de componentes distribuidos ms pequeos es
cada da ms acusada.

Previamente a la existencia de SOAP, no existan buenas interfaces para

acceder a las funcionalidades de otros ordenadores en red. Las que haba
eran poco conocidas, tales como EDI, RPC, u otras APIs.

Inconvenientes:
 En relacin a las transacciones, no pueden compararse su grado de
desarrollo con los estndares abiertos de computacin distribuida como
CORBA.

Su rendimiento es bajo si se compara con otros modelos de computacin

distribuida, tales como RMI, CORBA, o DCOM. Es uno de los inconvenientes
derivados de adoptar un formato basado en texto. Adems, entre los
objetivos de XML no se encuentra la concisin ni la eficacia de
procesamiento.

Al apoyarse en HTTP, pueden esquivar medidas de seguridad basadas en

cortafuegos cuyas reglas tratan de bloquear o auditar la comunicacin entre
aplicaciones a ambos lados de la barrera.

Existe poca informacin de servicios web para algunos lenguajes de

programacin.

5.4. Arquitectura Tcnica: Protocolos

Las aplicaciones web actuales ya no son suficientes. El modelo actual de negocio
electrnico no facilita la integracin de las aplicaciones de Internet con el resto de
software de las empresas. Si las compaas quieren extraer el mximo beneficio de
Internet, los sitios web deben evolucionar. Este es el contexto en el que surgen los
servicios web.

Como hemos visto, los servicios web son componentes software que permiten a los
usuarios usar aplicaciones de negocio que comparten datos con otros programas
modulares, va Internet.

Son aplicaciones independientes de la plataforma que pueden ser fcilmente

publicadas, localizadas e invocadas mediante protocolos web estndar, como XML,
SOAP, UDDI o WSDL. El objetivo final es la creacin de un directorio online de
servicios web, que pueda ser localizado de un modo sencillo y que tenga una alta
fiabilidad.

La funcionalidad de los protocolos empleados es la siguiente:

XML (eXtensible Markup Language Lenguaje de marcado

extensible): Un servicio web es una aplicacin web creada en XML.

WSDL (Web Services Definition Language Lenguaje de Descripcin

de Servicios Web): Describe el servicio web cuando ste es publicado. Es
el lenguaje XML que los proveedores emplean para describir sus servicios
web.
 Permite que un servicio y un cliente establezcan un acuerdo en lo que se
refiere a los detalles de transporte de mensajes y su contenido, a travs de
un documento procesable por dispositivos.

WSDL representa una especie de contrato entre el proveedor y el que

solicita. WSDL especifica la sintaxis y los mecanismos de intercambio de
mensajes.

SOAP (Simple Object Access Protocol Protocolo Sencillo de Acceso

a Objetos): Permite que programas que corren en diferentes sistemas
operativos se comuniquen. La comunicacin entre las diferentes entidades
se realiza mediante mensajes que son rutados en un sobre SOAP.

UDDI (Universal Description Discovery and Integration

Descripcin, Descubrimiento e Integracin Universal): Permite la
publicacin y localizacin de los servicios. Los directorios UDDI actan como
una gua telefnica de servicios web.

En los apartados siguientes los estudiamos con ms detalle.

5.4.1. SOAP

SOAP es el protocolo de comunicaciones para los servicios Web XML. Al estar

descrito como protocolo de comunicaciones, SOAP incluye aspectos como la
invocacin de objetos o un servicio de nombres, pero no los especifica. SOAP es un
protocolo que define el formato XML para los mensajes, y sa es la nica parte a la
que hace referencia la especificacin. Si tenemos un fragmento XML correctamente
definido e incluido en un par de elementos SOAP, tenemos un mensaje SOAP.

Existen otras partes de la especificacin SOAP que describen cmo representar

datos de programas utilizando XML y cmo utilizar SOAP para realizar llamadas a
procedimientos remotos. Estas partes opcionales de la especificacin se utilizan
para implementar aplicaciones de tipo RPC donde un mensaje SOAP que contiene
una funcin invocable, y los parmetros que se pasan a la funcin, se envan desde
el cliente, y el servidor devuelve un mensaje con los resultados de la ejecucin de
la funcin.

La mayora de las implementaciones actuales de SOAP soportan aplicaciones RPC

porque los programadores que estn acostumbrados a crear aplicaciones COM o
CORBA ya conocen el estilo RPC. SOAP tambin soporta aplicaciones de tipo
documental en las que el mensaje SOAP es simplemente un envoltorio sobre un
documento XML. Las aplicaciones SOAP de tipo documental son muy flexibles y
muchos servicios Web XML nuevos aprovechan esta flexibilidad para construir
servicios que seran difciles de implementar utilizando RPC.
 Estructura de un mensaje SOAP.

Los datos pueden ser transmitidos a travs de HTTP , SMTP , etc. SOAP especifica el
formato de los mensajes. El mensaje SOAP est compuesto por un envelope (sobre),
cuya estructura est formada por los siguientes elementos: header (cabecera) y
body (cuerpo).

La ltima parte opcional de la especificacin SOAP define el aspecto de un mensaje

HTTP que contiene un mensaje SOAP. Este enlace con HTTP es importante porque
HTTP est soportado por casi todos los sistemas operativos actuales (y muchos
otros no tan actuales).

El enlace HTTP es opcional, pero casi todas las implementaciones SOAP lo soportan,
porque es el nico protocolo estandarizado para SOAP. Por esta razn, existe la
idea generalizada y equivocada de que SOAP requiere HTTP. Algunas
implementaciones soportan transportes MSMQ, MQ Series, SMTP o TCP/IP, pero
casi todos los servicios Web XML actuales utilizan HTTP porque es ubicuo. Como
HTTP es un protocolo fundamental en la Web, la mayora de las organizaciones ya
tienen una infraestructura de red que soporta HTTP y personal que ya sabe cmo
gestionarlo. La infraestructura de seguridad, monitorizacin y balance de carga
para HTTP ya est ampliamente disponible en la actualidad.

Una fuente importante de confusin respecto a SOAP es la diferencia entre la

especificacin SOAP y las mltiples implementaciones de dicha especificacin. La
mayor parte de personas que utilizan SOAP no escriben mensajes SOAP
directamente, pero utilizan un kit de herramientas SOAP para crearlos. Estas
herramientas generalmente traducen llamadas a funciones con un cierto lenguaje a
un mensaje SOAP. Por ejemplo, el kit de herramientas Microsoft SOAP Toolkit
2.0 traduce llamadas de funciones COM a SOAP y Apache Toolkit traduce
llamadas de funciones Java a SOAP. Los tipos de llamadas a funciones y los tipos de
datos de los parmetros soportados varan en cada implementacin SOAP, de modo
que una funcin que funciona con un kit de herramientas puede no trabajar con
otro. sta no es una limitacin de SOAP, sino de una implementacin concreta.

La caracterstica ms convincente de SOAP es que ha sido implementado en

muchas plataformas hardware y software distintas. Esto significa que SOAP puede
utilizarse para enlazar sistemas dispares dentro y fuera de una organizacin. Se
han realizado muchos intentos en el pasado para que surgiese un protocolo de
comunicaciones comn que pudiese utilizarse para la integracin de sistemas, pero
ninguno ha tenido la amplia adopcin de SOAP, principalmente porque SOAP es
mucho menor y simple de implementar que muchos de los protocolos anteriores.

Por ejemplo, las implementaciones de DCE y CORBA tardaron aos, y slo se

liberaron unas pocas implementaciones. SOAP, sin embargo, puede utilizar los
parseadores XML y las libreras HTTP para realizar la mayor parte del trabajo duro,
de modo que es posible completar una implementacin SOAP en cuestin de
meses. sta es la razn de que haya ms de 70 implementaciones SOAP
disponibles. Obviamente SOAP no realiza todo lo que hace DCE o CORBA, pero la
falta de complejidad es lo que hace que SOAP est fcilmente disponible.

La ubicuidad de HTTP y la simplicidad de SOAP los convierten en una base ideal

para implementar servicios Web XML que pueden consumirse desde prcticamente
cualquier entorno.

5.4.2. WSDL

Un archivo WSDL es un documento XML que describe un conjunto de mensajes

SOAP y cmo se realiza el intercambio de mensajes. Como WSDL es XML, es legible
y editable pero, en la mayora de casos, se genera y se consume por parte de
software.

Utilizando una analoga con otras tecnologas, podemos afirmar que WSDL es a
SOAP lo que IDL es a CORBA o COM.

WSDL especifica el contenido de un mensaje de peticin y el aspecto del mensaje

de respuesta en una notacin inequvoca.

La notacin que utiliza un archivo WSDL para describir formatos de mensajes est
basada en el estndar XML Schema, siendo neutral respecto del lenguaje de
programacin ya que est basado en estndares; esto lo hace apropiado para
describir interfaces de servicios Web XML accesibles desde una amplia variedad de
plataformas y lenguajes de programacin.

Adems de describir el contenido de los mensajes, WSDL define dnde est

disponible el servicio y qu protocolo de comunicaciones utilizar para hablar con el
servicio. Esto significa que el archivo WSDL define todo lo necesario para escribir un
programa que interacte con un servicio Web XML.

Existen varias herramientas disponibles para leer un archivo WSDL y generar el

cdigo necesario para comunicarse con un servicio Web XML. Alguna de las mejores
se pueden encontrar en Microsoft Visual Studio .NET.

5.4.3. UDDI

Escoger la estructura adecuada para una aplicacin, especialmente una distribuida

a travs de varios sistemas, es de gran importancia. Generalmente, una mala
eleccin de arquitectura no puede arreglarse durante la implementacin, con
independencia de lo buenos que sean los desarrolladores. Tomar las decisiones
incorrectas lleva a un menor rendimiento, menor seguridad y una menor cantidad
de opciones cuando una aplicacin deba ser actualizada.

Universal Discovery Description and Integration (UDDI) son las pginas

amarillas de los servicios web. Al igual que con las pginas amarillas tradicionales,
podemos buscar una empresa que ofrezca los servicios que necesitamos, obtener
informacin sobre el servicio ofrecido y contactar con alguien para ms
informacin.

Se puede ofrecer un servicio Web sin registrarlo en UDDI, accin anloga a abrir un
negocio en un stano y confiar en la publicidad boca a boca de nuestros clientes. Si
se desea alcanzar un mercado significativo, UDDI es fundamental para que los
clientes puedan encontrarnos.

Una entrada de directorio UDDI es un archivo XML que describe un negocio

y los servicios que ofrece.

Una entrada en el directorio UDDI est formada por tres partes:

Pginas blancas: Describen la compaa que ofrece el servicio: nombre,

direccin, contactos, etc.

Pginas amarillas: Incluyen categoras industriales basadas en taxonomas

estndares como el North American Industry Classification System y el
Standard Industrial Classification.

Pginas verdes: Describen el interfaz al servicio con suficiente detalle para

alguien que desarrolle una aplicacin que consuma el servicio Web.
El modo en que se definen los servicios es mediante un documento UDDI llamado
Type Model o tModel. En muchos casos, tModel contiene un archivo WSDL que
describe un interfaz SOAP a un servicio web XML, pero tModel es suficientemente
flexible para describir prcticamente cualquier tipo de servicio.

El directorio UDDI tambin incluye varias formas de buscar los servicios que se
necesitan para construir aplicaciones. Por ejemplo, podemos buscar los
proveedores de un servicio en una ubicacin geogrfica especfica o un negocio de
un tipo especfico. El directorio UDDI proporciona informacin, contactos, enlaces e
informacin tcnica que permiten evaluar qu servicios satisfacen nuestros
requerimientos.

UDDI permite encontrar negocios que ofrecen servicios web. La especificacin WS-
Inspection permite navegar por una serie de servicios web ofrecidos en un
determinado servidor para encontrar los que satisfacen las necesidades especficas
que se puedan tener.

En resumen: Hemos definido un servicio Web XML como un servicio

software expuesto en la Web mediante SOAP, descrito con un archivo
WSDL y registrado en UDDI.

El siguiente grfico muestra cmo interacta un conjunto de Servicios Web:

Arquitectura de un sistema basado en servicios web.

Segn el ejemplo del grfico, un usuario (que juega el papel de cliente dentro de
los Servicios Web), a travs de una aplicacin, solicita informacin sobre un viaje
que desea realizar haciendo una peticin a una agencia de viajes que ofrece sus
servicios a travs de Internet.
La agencia de viajes ofrecer a su cliente (usuario) la informacin requerida. Para
proporcionar al cliente la informacin que necesita, esta agencia de viajes solicita a
su vez informacin a otros recursos (otros Servicios Web) en relacin con el hotel y
la lnea area.

La agencia de viajes obtendr informacin de estos recursos, lo que la convierte a

su vez en cliente de esos otros Servicios Web que le van a proporcionar la
informacin solicitada sobre el hotel y la lnea area.

Por ltimo, el usuario realizar el pago del viaje a travs de la agencia de viajes
que servir de intermediario entre el usuario y el servicio Web que gestionar el
pago.

5.5. Organismos Normalizadores

Los servicios web estn basados en el estndar XML, que ha sido universalmente
aceptado. Pero la situacin para el resto de protocolos es bien distinta. La mayor
parte de ellos se encuentran todava en desarrollo y pueden ser objeto de cambios.
Esa es la razn por la que la mayora de las empresas estn esperando a que estos
protocolos sean ms universales antes de profundizar en esta tecnologa.

Actualmente, ni SOAP, ni WSDL, ni UDDI han sido oficialmente reconocidos por

ningn organismo de estandarizacin. SOAP es el nico que en este momento est
en consideracin por el World Wide Web Consortium (W3C) y se encuentra
cercano a la estandarizacin.

SOAP y WSDL estn siendo ampliamente usados, pero de momento UDDI no ha

tenido el mismo xito. El principal motivo es que las tcnicas de seguridad son
todava muy inmaduras y las compaas prefieren hacer uso de registros privados
para dar soporte a intercambios privados de servicios web.

En febrero de 2007, algunas de las empresas muy importantes en el mbito

informtico multinacional como IBM, Intel, Microsoft o Oracle, han creado el WS-I:
organizacin para la Interoperabilidad de los Servicios web. El objetivo de
dicha organizacin es la promocin de la estandarizacin de los servicios web de
modo que se fomente la cooperacin e interoperabilidad entre las compaas y
mercados.
 Pgina web oficial de WS-I.

Por otra parte, OASIS (acrnimo de Organization for the Advancement of

Structured Information Standards) es un consorcio internacional sin fines de
lucro que orienta el desarrollo, la convergencia y la adopcin de los estndares e-
business (comercio electrnico).

OASIS ha aprobado la versin 2.0 de UDDI.

5.6. Estndares Establecidos

Servicios web Protocol Stack: Conjunto de servicios y protocolos de los
servicios Web.

XML: Formato estndar para los datos a intercambiar.

 WSDL: Lenguaje de la interfaz pblica para los servicios Web. Descripcin
basada en XML de los requisitos funcionales necesarios para establecer una
comunicacin con los servicios Web.

SOAP o XML-RPC: Protocolos sobre los que se establece el intercambio.

UDDI: Protocolo para publicar la informacin de los servicios Web. Permite

a las aplicaciones comprobar qu servicios web estn disponibles.

WS-Security: Protocolo de seguridad aceptado como estndar por OASIS.

Garantiza la autenticacin de los actores y la confidencialidad de los
mensajes enviados.

Otros protocolos: Los datos en XML tambin pueden enviarse de una

aplicacin a otra mediante protocolos estandarizados como HTTP, FTP, o
SMTP.

5.7. Plataformas Actuales

La siguiente lista contiene los principales servidores de aplicaciones para servicios
Web:

Microsoft.NET

WebLogic

WebSphere

Axis y el servidor Jakarta Tomcat (de Apache)

Java Servicios web Development Pack (JWSDP) de Sun Microsystems

(basado en Jakarta Tomcat)

ColdFusion MX de Macromedia

JOnAS (parte de ObjectWeb una iniciativa de cdigo abierto)

Novell exteNd (basado en la plataforma J2EE)

Zope es un servidor de aplicaciones Web orientado a objetos desarrollado en

el lenguaje de programacin Python

VERASTREAM de AttachmateWRQ para modernizar o integrar aplicaciones

host IBM y VT

5.8. Seguridad
Actualmente, los servicios web estn siendo ampliamente aceptados por las
empresas para el desarrollo de software de uso interno. As los servicios pueden
implementar toda su funcionalidad y permanecer seguros tras el cortafuegos de la
compaa.
En contraposicin, los desarrollos actuales no ayudan a la cooperacin entre las
empresas ya que no existe ningn estndar establecido sobre las tcnicas de
seguridad. Debido a la tecnologa usada por los servicios web (en concreto SOAP),
las tcnicas de seguridad convencionales utilizadas en Internet no resultan
suficientes.

Con SOAP cada mensaje intercambiado realiza mltiples saltos, siendo dirigido a
travs de numerosos puntos intermedios antes de alcanzar su destino final. Por ello
los servicios web necesitan tecnologas que protejan los mensajes a lo largo de su
ruta completa.

Existen un conjunto de tcnicas que garantizan la seguridad a nivel de mensaje:

Encriptacin XML: Evita que los datos se vean expuestos a lo largo de su

recorrido.

Firma Digital XML: Asocia los datos del mensaje al usuario que emite la
firma, de modo que este usuario es el nico que puede modificar dichos
datos.

XKMS (XML Key Management Specification) y los Certificados: Define

servicios web que se pueden usar para chequear la confianza de un
certificado de usuario.

SAML (Security Assertion Mark-up Language) y la Autorizacin:

Posibilita que los servicios web intercambien informacin de autentificacin y
autorizacin entre ellos, por ejemplo que un servicio web confe en un
usuario autentificado por otro servicio.

Validacin de datos: Garantiza a los servicios web que recibirn datos

cuyos valores se encuentren dentro de los rangos esperados.

Adems de lo expuesto existen otras tcnicas que permiten mantener la seguridad

en niveles adicionales, por ejemplo la seguridad en UDDI permite autentificar todas
las entidades que toman parte en la publicacin de un servicio web: proveedor,
agente y consumidor del servicio. De este modo, nadie podr registrar servicios en
el papel de un proveedor o hacer uso de ellos sin contar con los permisos
adecuados.

En relacin con SOAP, en las primeras etapas de su desarrollo, se perciba como un

protocolo basado en HTTP, y por ello se supuso que la seguridad HTTP sera
adecuada para SOAP. Despus de todo, existen miles de aplicaciones Web
ejecutndose en la actualidad que utilizan seguridad HTTP, de modo que
seguramente tambin ser adecuada para SOAP. Por esta razn, el estndar SOAP
actual asume que la seguridad es una cuestin de transporte y no indica nada sobre
los aspectos de seguridad.
Cuando SOAP se expandi hasta convertirse en un protocolo de propsito general
ejecutndose sobre diversos transportes, la seguridad se convirti en un aspecto
ms importante. Por ejemplo, HTTP proporciona varios modos de autenticar qu
usuario est realizando una llamada SOAP, pero cmo se propaga esa identidad
cuando el mensaje se rutea desde un transporte HTTP a SMTP? SOAP se dise
como un protocolo de bloque de construccin de modo que, afortunadamente, ya
existen especificaciones en trabajos basados en SOAP para proporcionar
funcionalidades de seguridad adicionales para los servicios Web. La especificacin
WS-Security define un sistema de encriptacin completo.

5.9. Calidad

La calidad de un servicio web es un parmetro que no queda demasiado claro, pero

cuya medida es fundamental a la hora de desarrollar un servicio maduro.

Actualmente existen en el mercado algunas herramientas especficamente

diseadas para medir la calidad de los servicios web, pero sigue siendo necesaria
una estandarizacin sobre este tema.

Los resultados sobre la calidad de diferentes servicios web servirn como

parmetro de comparacin y ayudarn al usuario a decantarse por un servicio u
otro.

Para que un web service se ejecute con correccin y satisfaga las expectativas
creadas, a parte del precio, habr que tener en cuenta una serie de parmetros
como por ejemplo, que los resultados obtenidos del mismo sean los esperados o
que el entorno de uso sea amigable.

Otro elemento a tener en cuenta es la integracin. Aunque tericamente los

servicios web proporcionan conectividad con cualquier software de un modo
transparente, cada proveedor de servicios puede adoptar soluciones diferentes que
resultan ms o menos adecuadas para el consumidor.

Analizando la escalabilidad se comprobar el grado de modularidad y

flexibilidad del servicio.

Por ltimo, tambin sera interesante analizar las caractersticas que ofrece el
proveedor de servicios web. Actualmente no existen estndares al respecto, pero la
mayora de las empresas ya est demandando algn tipo de acuerdo o contrato con
los proveedores, de modo que se pueda garantizar la calidad y la fiabilidad de los
servicios contratados.
5.10. Algunos Ejemplos
Empresas multinacionales muy conocidas y muchas otras ms discretas han
empezado a desarrollar soluciones mediante tecnologa servicios web. A
continuacin se incluyen algunos ejemplos significativos:

Microsoft: Lanz la versin 2006 de su primer web service, denominado

MapPoint.Net. Mediante este servicio, el usuario podr conocer su
localizacin exacta y otros datos adicionales relacionados con su posicin
actual, como informacin de trfico, rutas posibles o puntos comerciales
cercanos.

IBM: Ha implementado una solucin basada en los servicios web llamada e-

Business on Demand. Esta solucin permite la construccin de extranets
que ayuden a las empresas a ver los catlogos de productos, realizar y
localizar pedidos o chequear el estado del inventario en tiempo real.

Lneas Areas Escandinavas: Estas lneas areas han desarrollado un

servicio web que permite a los usuarios comprar billetes y chequear el
estado de los vuelos, mediante el uso del telfono mvil.

5.11. Comparativa con otras Tecnologas

Una de las ventajas principales de la arquitectura de servicios web es que permite a
los programas escritos en diferentes lenguajes sobre diferentes plataformas
comunicarse entre s de un modo basado en estndares.

Este mercado ofreca estas posibilidades desde hace tiempo: CORBA (Common
Object Request Broker Architecture) y antes incluso DCE (Distributed Computing
Environment). Cul es la diferencia con estas tecnologas?. La primera disparidad
es que SOAP es bastante menos complejo que las anteriores aproximaciones, de
modo que la barrera de entrada para una implementacin SOAP compatible con los
estndares es significativamente menor.

Encontraremos implementaciones SOAP de las mayores compaas de software,

como sera de esperar, pero tambin encontraremos muchas implementaciones
desarrolladas y mantenidas por un nico desarrollador.

La otra ventaja significativa que tienen los servicios Web XML sobre anteriores
iniciativas es que trabajan con protocolos web estndares: XML, HTTP y TCP/IP. Un
significativo nmero de compaas ya tienen una infraestructura Web y personal
con conocimiento y experiencia en su mantenimiento, de modo que, nuevamente,
la barrera de entrada de los servicios web XML es considerablemente menor que las
tecnologas anteriores.
5.12. El Futuro Prximo
En apartados anteriores hemos hablado sobre cmo hablar con los servicios Web
XML (SOAP), cmo se describen los servicios Web XML (WSDL) y cmo encontrar
los servicios Web XML (UDDI). Estos protocolos constituyen un conjunto de
especificaciones que proporcionan la base para la integracin y agregacin de
aplicaciones.

Desde estas especificaciones base, las empresas estn generando soluciones reales
y obteniendo valor real de las mismas. Aunque se ha trabajado mucho para que los
servicios Web XML sean una realidad, es necesario hacer mucho ms.

Los primeros servicios web XML solan ser fuentes de informacin que podamos
fcilmente incorporar en las aplicaciones (cotizaciones de valores, previsiones del
tiempo, resultados deportivos, etc.).

Actualmente los servicios web XML tienen un gran xito entre el pblico, pero
todava hay temas sobre los que los desarrolladores deben seguir trabajando; por
ejemplo, la seguridad, gestin operacional, transacciones, mensajera fiable, etc.

La arquitectura Global XML Web Services Architecture (GXA) permitir que los
servicios Web XML evolucionen ofreciendo un modelo consistente y de propsito
general para aadir nuevas capacidades avanzadas a los servicios Web XML de
modo modular y extensible. WS-Security es una de las especificaciones de GXA.
Las necesidades de la gestin operacional como el routing de mensajes entre
mltiples servidores y la configuracin dinmica de estos servidores tambin
forman parte de la arquitectura GXA, y se satisfacen por la especificacin WS-
Routing y la especificacin WS-Referral. A medida que la arquitectura GXA
crezca, se presentarn especificaciones para estas y otras necesidades.

En el futuro, algunos de los servicios Web XML ms interesantes soportarn

aplicaciones que utilizarn la Web para hacer cosas que no pueden hacer hoy. Por
ejemplo, uno de los servicios que el proyecto Microsoft .NET My Services soportar
es un servicio de calendario. Si un dentista o mecnico expusiesen sus calendarios
mediante este servicio Web XML, se podran planificar citas en lnea.

Es fcil imaginar un conjunto completo de aplicaciones que podran ser

desarrolladas para analizar y agregar informacin importante y que la presentase
de varias formas; por ejemplo, podramos tener una hoja de clculo Excel que
integrase una imagen financiera completa (cotizaciones, cuentas bancarias,
prstamos, etc.). Si esta informacin est disponible mediante servicios web XML,
Excel puede actualizarla continuamente. Parte de esta informacin ser gratuita y
parte podra requerir de una suscripcin al servicio.
La mayora de esta informacin est ya disponible en la Web, pero los servicios
Web XML harn que su acceso programtico sea ms fcil y fiable.

Exponer las aplicaciones existentes como servicios web XML permitir a los usuarios
construir nuevas y ms potentes aplicaciones que utilicen estos servicios como
bloques de construccin. Por ejemplo, un usuario podra desarrollar una aplicacin
de compras para obtener automticamente la informacin de precios de varios
fabricantes, que permitiera seleccionar un fabricante, enviar el pedido y a
continuacin realizar seguimiento del envo hasta que sea recibido. La aplicacin del
fabricante, adems de exponer sus servicios en la Web, podra a su vez utilizar
servicios web XML para verificar el crdito del cliente, realizar un cargo en su
cuenta y realizar el envo con una empresa de transporte.