TEMA 12 5. ARQUITECTURA DE SERVICIOS WEB (WS) 5.1

TEMA 12
5. ARQUITECTURA DE SERVICIOS WEB
(WS)
5.1. Introducción
Desde mediado de la década de los 90, con la aparición y extensión de Internet a
niveles jamás pensados, ha existido siempre la necesidad de integración entre
sistemas muy heterogéneos, tanto software como hardware. Muchas empresas
comenzaron grandes proyectos para lograr la mejor tecnología integradora de
sistemas, pero a medida que la competencia se hacia cada vez más fuerte, la
integración se hacia cada vez más difícil.
Estas empresas pronto se percataron que la imposibilidad de crear una plataforma
integrada de forma individual; se haría necesario atacar el problema de raíz,
buscando un lenguaje común de intercambio de información aprovechando
los estándares existentes en el mercado. Bajo este contexto nacen los
Servicios Web basados en XML
5.2. Definición
Un servicio Web (Web service) es una colección de protocolos y estándares que
sirven para intercambiar datos entre aplicaciones. La interoperabilidad se consigue
mediante la adopción de estándares abiertos.
Estos servicios proporcionan mecanismos de comunicación estándares entre
diferentes aplicaciones, que interactúan entre sí para presentar información
dinámica al usuario. Para proporcionar interoperabilidad y extensibilidad entre estas
aplicaciones, y que al mismo tiempo sea posible su combinación para realizar
operaciones complejas, es necesaria una arquitectura de referencia estándar.
Distintas aplicaciones de software desarrolladas en lenguajes de programación
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 descripción que englobe todo lo que son e implican
los servicios web. A continuación ofrecemos algunas:
•
Conjunto de aplicaciones o de tecnologías con capacidad para interoperar en
la Web. Estas aplicaciones o tecnologías 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 través de la Web.
•
Componentes software que permiten a los usuarios usar aplicaciones que
comparten datos con otros programas modulares, vía Internet.
•
Aplicaciones independientes de la plataforma que pueden ser fácilmente
publicadas, localizadas e invocadas mediante protocolos web estándar, como
XML, SOAP, UDDI o WSDL. El objetivo final es la creación de un directorio
online de servicios web que pueda ser localizado de un modo sencillo y que
tenga una alta fiabilidad.
•
Nueva generación de aplicaciones que trabajan colaborativamente en las
cuáles el software esta distribuido en diferentes servidores.
Como podemos apreciar, probablemente existan tantas definiciones de los Servicios
Web como compañías que los desarrollan, pero casi todas las definiciones se
desarrollan sobre estos aspectos técnicos comunes:
•
Los Servicios Web exponen funcionalidad útil a los usuarios Web mediante
un protocolo Web estándar. En la mayoría 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 aplicación cliente
para comunicarse con ellos. Esta descripción 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 programación modular no es nueva, el éxito de esta tecnología
reside en que se basa en estándares conocidos en los que ya se tiene una gran
confianza, como el XML. Además, el uso de los servicios web aporta ventajas
significativas
a
las
empresas.
El
principal
objetivo
que
se
logra,
es
la
interoperabilidad y la integración. Mediante los servicios web, las empresas pueden
compartir servicios software con sus clientes, socios, proveedores, etc.
Esto ayudará a las compañías a escalar sus negocios, reduciendo el coste en
desarrollo y mantenimiento de software, y lanzando productos al mercado con
mayor rapidez. La integración de aplicaciones hará posible obtener la información
demandada en tiempo real, acelerando el proceso de toma de decisiones. La
evolución de Internet hacia los servicios web, mejorará los resultados globales de
las empresas, reduciendo sus gastos y guiándolas hacia una mejora progresiva de
la calidad. La adopción de la tecnología de servicios web por la industria puede
suponer el primer paso hacia una economía 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 estándar.
•
Los servicios web fomentan los estándares y protocolos basados en texto,
que hacen más fácil 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
razón 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 tráfico 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 razón de que no resultan bloqueados.
•
Permiten que servicios y software de diferentes compañías ubicadas en
diferentes lugares geográficos puedan ser combinados fácilmente para
proveer servicios integrados.
•
Los servicios web son muy prácticos al aportar gran independencia entre la
aplicación 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 más importante, dado que la tendencia a construir
grandes aplicaciones a partir de componentes distribuidos más pequeños es
cada día más acusada.
•
Previamente a la existencia de SOAP, no existían buenas interfaces para
acceder a las funcionalidades de otros ordenadores en red. Las que había
eran poco conocidas, tales como EDI, RPC, u otras APIs.
Inconvenientes:
•
En relación a las transacciones, no pueden compararse su grado de
desarrollo con los estándares abiertos de computación distribuida como
CORBA.
•
Su rendimiento es bajo si se compara con otros modelos de computación
distribuida, tales como RMI, CORBA, o DCOM. Es uno de los inconvenientes
derivados de adoptar un formato basado en texto. Además, entre los
objetivos
de
XML
no
se
encuentra
la
concisión
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 comunicación entre
aplicaciones a ambos lados de la barrera.
•
Existe poca información de servicios web para algunos lenguajes de
programación.
5.4. Arquitectura Técnica: Protocolos
Las aplicaciones web actuales ya no son suficientes. El modelo actual de negocio
electrónico no facilita la integración de las aplicaciones de Internet con el resto de
software de las empresas. Si las compañías quieren extraer el máximo 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, vía Internet.
Son aplicaciones independientes de la plataforma que pueden ser fácilmente
publicadas, localizadas e invocadas mediante protocolos web estándar, como XML,
SOAP, UDDI o WSDL. El objetivo final es la creación 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 aplicación web creada en XML.
•
WSDL (Web Services Definition Language – Lenguaje de Descripción
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 través 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 comunicación entre las diferentes entidades
se realiza mediante mensajes que son rutados en un “sobre SOAP”.
•
UDDI
(Universal
Description
Discovery
and
Integration
–
Descripción, Descubrimiento e Integración Universal): Permite la
publicación y localización de los servicios. Los directorios UDDI actúan como
una guía telefónica de servicios web.
En los apartados siguientes los estudiamos con más 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
invocación 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 especificación. Si tenemos un fragmento XML correctamente
definido e incluido en un par de elementos SOAP, tenemos un mensaje SOAP.
Existen otras partes de la especificación SOAP que describen cómo representar
datos de programas utilizando XML y cómo utilizar SOAP para realizar llamadas a
procedimientos remotos. Estas partes opcionales de la especificación se utilizan
para implementar aplicaciones de tipo RPC donde un mensaje SOAP que contiene
una función invocable, y los parámetros que se pasan a la función, se envían desde
el cliente, y el servidor devuelve un mensaje con los resultados de la ejecución de
la función.
La mayoría de las implementaciones actuales de SOAP soportan aplicaciones RPC
porque los programadores que están acostumbrados a crear aplicaciones COM o
CORBA ya conocen el estilo RPC. SOAP también 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 serían difíciles de implementar utilizando RPC.
Estructura de un mensaje SOAP.
Los datos pueden ser transmitidos a través 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 especificación 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 razón, 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 mayoría de las organizaciones ya
tienen una infraestructura de red que soporta HTTP y personal que ya sabe cómo
gestionarlo. La infraestructura de seguridad, monitorización y balance de carga
para HTTP ya está ampliamente disponible en la actualidad.
Una fuente importante de confusión respecto a SOAP es la diferencia entre la
especificación SOAP y las múltiples implementaciones de dicha especificación. 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 parámetros soportados varían en cada implementación SOAP, de modo
que una función que funciona con un kit de herramientas puede no trabajar con
otro. Ésta no es una limitación de SOAP, sino de una implementación concreta.
La característica más 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 organización. Se
han realizado muchos intentos en el pasado para que surgiese un protocolo de
comunicaciones común que pudiese utilizarse para la integración de sistemas, pero
ninguno ha tenido la amplia adopción 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 años, y sólo se
liberaron unas pocas implementaciones. SOAP, sin embargo, puede utilizar los
parseadores XML y las librerías HTTP para realizar la mayor parte del trabajo duro,
de modo que es posible completar una implementación SOAP en cuestión de
meses. Ésta es la razón de que haya más 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é fácilmente 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 prácticamente
cualquier entorno.
5.4.2. WSDL
Un archivo WSDL es un documento XML que describe un conjunto de mensajes
SOAP y cómo se realiza el intercambio de mensajes. Como WSDL es XML, es legible
y editable pero, en la mayoría de casos, se genera y se consume por parte de
software.
Utilizando una analogía con otras tecnologías, podemos afirmar que WSDL es a
SOAP lo que IDL es a CORBA o COM.
WSDL especifica el contenido de un mensaje de petición y el aspecto del mensaje
de respuesta en una notación inequívoca.
La notación que utiliza un archivo WSDL para describir formatos de mensajes está
basada en el estándar XML Schema, siendo neutral respecto del lenguaje de
programación ya que está basado en estándares; esto lo hace apropiado para
describir interfaces de servicios Web XML accesibles desde una amplia variedad de
plataformas y lenguajes de programación.
Además de describir el contenido de los mensajes, WSDL define dónde 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 interactúe con un servicio Web XML.
Existen varias herramientas disponibles para leer un archivo WSDL y generar el
código 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 aplicación, especialmente una distribuida
a través de varios sistemas, es de gran importancia. Generalmente, una mala
elección de arquitectura no puede arreglarse durante la implementación, 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 aplicación deba ser actualizada.
Universal Discovery Description and Integration (UDDI) son las páginas
amarillas de los servicios web. Al igual que con las páginas amarillas tradicionales,
podemos buscar una empresa que ofrezca los servicios que necesitamos, obtener
información
sobre
el
servicio
ofrecido
y
contactar
con
alguien
para
más
información.
Se puede ofrecer un servicio Web sin registrarlo en UDDI, acción análoga a abrir un
negocio en un sótano 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:
•
Páginas blancas: Describen la compañía que ofrece el servicio: nombre,
dirección, contactos, etc.
•
Páginas amarillas: Incluyen categorías industriales basadas en taxonomías
estándares como el North American Industry Classification System y el
Standard Industrial Classification.
•
Páginas verdes: Describen el interfaz al servicio con suficiente detalle para
alguien que desarrolle una aplicación 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 prácticamente cualquier tipo de servicio.
El directorio UDDI también incluye varias formas de buscar los servicios que se
necesitan
para
construir
aplicaciones.
Por
ejemplo,
podemos
buscar
los
proveedores de un servicio en una ubicación geográfica específica o un negocio de
un tipo específico. El directorio UDDI proporciona información, contactos, enlaces e
información técnica que permiten evaluar qué servicios satisfacen nuestros
requerimientos.
UDDI permite encontrar negocios que ofrecen servicios web. La especificación WSInspection permite navegar por una serie de servicios web ofrecidos en un
determinado servidor para encontrar los que satisfacen las necesidades específicas
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 gráfico muestra cómo interactúa un conjunto de Servicios Web:
Arquitectura de un sistema basado en servicios web.
Según el ejemplo del gráfico, un usuario (que juega el papel de cliente dentro de
los Servicios Web), a través de una aplicación, solicita información sobre un viaje
que desea realizar haciendo una petición a una agencia de viajes que ofrece sus
servicios a través de Internet.
La agencia de viajes ofrecerá a su cliente (usuario) la información requerida. Para
proporcionar al cliente la información que necesita, esta agencia de viajes solicita a
su vez información a otros recursos (otros Servicios Web) en relación con el hotel y
la línea aérea.
La agencia de viajes obtendrá información de estos recursos, lo que la convierte a
su vez en cliente de esos otros Servicios Web que le van a proporcionar la
información solicitada sobre el hotel y la línea aérea.
Por último, el usuario realizará el pago del viaje a través 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 están basados en el estándar XML, que ha sido universalmente
aceptado. Pero la situación para el resto de protocolos es bien distinta. La mayor
parte de ellos se encuentran todavía en desarrollo y pueden ser objeto de cambios.
Esa es la razón por la que la mayoría de las empresas están esperando a que estos
protocolos sean más universales antes de profundizar en esta tecnología.
Actualmente, ni SOAP, ni WSDL, ni UDDI han sido oficialmente reconocidos por
ningún organismo de estandarización. SOAP es el único que en este momento está
en consideración por el World Wide Web Consortium (W3C) y se encuentra
cercano a la estandarización.
SOAP y WSDL están siendo ampliamente usados, pero de momento UDDI no ha
tenido el mismo éxito. El principal motivo es que las técnicas de seguridad son
todavía muy inmaduras y las compañías 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
informático multinacional como IBM, Intel, Microsoft o Oracle, han creado el WS-I:
organización para la Interoperabilidad de los Servicios web. El objetivo de
dicha organización es la promoción de la estandarización de los servicios web de
modo que se fomente la cooperación e interoperabilidad entre las compañías y
mercados.
Página web oficial de WS-I.
Por otra parte, OASIS (acrónimo 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 adopción de los estándares ebusiness (comercio electrónico).
OASIS ha aprobado la versión 2.0 de UDDI.
5.6. Estándares Establecidos
•
Servicios web Protocol Stack: Conjunto de servicios y protocolos de los
servicios Web.
•
XML: Formato estándar para los datos a intercambiar.
•
WSDL: Lenguaje de la interfaz pública para los servicios Web. Descripción
basada en XML de los requisitos funcionales necesarios para establecer una
comunicación con los servicios Web.
•
•
SOAP o XML-RPC: Protocolos sobre los que se establece el intercambio.
UDDI: Protocolo para publicar la información de los servicios Web. Permite
a las aplicaciones comprobar qué servicios web están disponibles.
•
WS-Security: Protocolo de seguridad aceptado como estándar por OASIS.
Garantiza la autenticación de los actores y la confidencialidad de los
mensajes enviados.
•
Otros protocolos: Los datos en XML también pueden enviarse de una
aplicación 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 código abierto)
•
Novell exteNd (basado en la plataforma J2EE)
•
Zope es un servidor de aplicaciones Web orientado a objetos desarrollado en
el lenguaje de programación Python
•
VERASTREAM de AttachmateWRQ para modernizar o integrar aplicaciones
host IBM y VT
5.8. Seguridad
Actualmente, los servicios web están 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
compañía.
En contraposición, los desarrollos actuales no ayudan a la cooperación entre las
empresas ya que no existe ningún estándar establecido sobre las técnicas de
seguridad. Debido a la tecnología usada por los servicios web (en concreto SOAP),
las técnicas de seguridad convencionales utilizadas en Internet no resultan
suficientes.
Con SOAP cada mensaje intercambiado realiza múltiples saltos, siendo dirigido a
través de numerosos puntos intermedios antes de alcanzar su destino final. Por ello
los servicios web necesitan tecnologías que protejan los mensajes a lo largo de su
ruta completa.
Existen un conjunto de técnicas que garantizan la seguridad a nivel de mensaje:
•
Encriptación 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 Autorización:
Posibilita que los servicios web intercambien información de autentificación y
autorización entre ellos, por ejemplo que un servicio web confíe en un
usuario autentificado por otro servicio.
•
Validación de datos: Garantiza a los servicios web que recibirán datos
cuyos valores se encuentren dentro de los rangos esperados.
Además de lo expuesto existen otras técnicas que permiten mantener la seguridad
en niveles adicionales, por ejemplo la seguridad en UDDI permite autentificar todas
las entidades que toman parte en la publicación 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 relación con SOAP, en las primeras etapas de su desarrollo, se percibía como un
protocolo basado en HTTP, y por ello se supuso que la seguridad HTTP sería
adecuada para SOAP. Después de todo, existen miles de aplicaciones Web
ejecutándose en la actualidad que utilizan seguridad HTTP, de modo que
seguramente también será adecuada para SOAP. Por esta razón, el estándar SOAP
actual asume que la seguridad es una cuestión de transporte y no indica nada sobre
los aspectos de seguridad.
Cuando SOAP se expandió hasta convertirse en un protocolo de propósito general
ejecutándose sobre diversos transportes, la seguridad se convirtió en un aspecto
más importante. Por ejemplo, HTTP proporciona varios modos de autenticar qué
usuario está realizando una llamada SOAP, pero ¿cómo se propaga esa identidad
cuando el mensaje se rutea desde un transporte HTTP a SMTP? SOAP se diseñó
como un protocolo de bloque de construcción de modo que, afortunadamente, ya
existen
especificaciones
en
trabajos
basados
en
SOAP
para
proporcionar
funcionalidades de seguridad adicionales para los servicios Web. La especificación
WS-Security define un sistema de encriptación completo.
5.9. Calidad
La calidad de un servicio web es un parámetro 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
específicamente
diseñadas para medir la calidad de los servicios web, pero sigue siendo necesaria
una estandarización sobre este tema.
Los resultados sobre la calidad de diferentes servicios web servirán como
parámetro de comparación y ayudarán al usuario a decantarse por un servicio u
otro.
Para que un web service se ejecute con corrección y satisfaga las expectativas
creadas, a parte del precio, habrá que tener en cuenta una serie de parámetros
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 integración. Aunque teóricamente los
servicios web proporcionan conectividad con cualquier software de un modo
transparente, cada proveedor de servicios puede adoptar soluciones diferentes que
resultan más o menos adecuadas para el consumidor.
Analizando
la
escalabilidad
se
comprobará
el
grado
de
modularidad
y
flexibilidad del servicio.
Por último, también sería interesante analizar las características que ofrece el
proveedor de servicios web. Actualmente no existen estándares al respecto, pero la
mayoría de las empresas ya está demandando algún 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 más discretas han
empezado
a
desarrollar
soluciones
mediante
tecnología
servicios
web.
A
continuación se incluyen algunos ejemplos significativos:
•
Microsoft: Lanzó la versión 2006 de su primer web service, denominado
MapPoint.Net. Mediante este servicio, el usuario podrá conocer su
localización exacta y otros datos adicionales relacionados con su posición
actual, como información de tráfico, rutas posibles o puntos comerciales
cercanos.
•
IBM: Ha implementado una solución basada en los servicios web llamada eBusiness on Demand. Esta solución permite la construcción de extranets
que ayuden a las empresas a ver los catálogos de productos, realizar y
localizar pedidos o chequear el estado del inventario en tiempo real.
•
Líneas Aéreas Escandinavas: Estas líneas aéreas han desarrollado un
servicio web que permite a los usuarios comprar billetes y chequear el
estado de los vuelos, mediante el uso del teléfono móvil.
5.11. Comparativa con otras Tecnologías
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 estándares.
Este mercado ofrecía estas posibilidades desde hace tiempo: CORBA (Common
Object Request Broker Architecture) y antes incluso DCE (Distributed Computing
Environment). ¿Cuál es la diferencia con estas tecnologías?. La primera disparidad
es que SOAP es bastante menos complejo que las anteriores aproximaciones, de
modo que la barrera de entrada para una implementación SOAP compatible con los
estándares es significativamente menor.
Encontraremos implementaciones SOAP de las mayores compañías de software,
como sería de esperar, pero también 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 estándares: XML, HTTP y TCP/IP. Un
significativo número de compañías 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
tecnologías anteriores.
5.12. El Futuro Próximo
En apartados anteriores hemos hablado sobre cómo hablar con los servicios Web
XML (SOAP), cómo se describen los servicios Web XML (WSDL) y cómo encontrar
los servicios Web XML (UDDI). Estos protocolos constituyen un conjunto de
especificaciones que proporcionan la base para la integración y agregación de
aplicaciones.
Desde estas especificaciones base, las empresas están 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 más.
Los primeros servicios web XML solían ser fuentes de información que podíamos
fácilmente incorporar en las aplicaciones (cotizaciones de valores, previsiones del
tiempo, resultados deportivos, etc.).
Actualmente los servicios web XML tienen un gran éxito entre el público, pero
todavía hay temas sobre los que los desarrolladores deben seguir trabajando; por
ejemplo, la seguridad, gestión operacional, transacciones, mensajería fiable, etc.
La arquitectura Global XML Web Services Architecture (GXA) permitirá que los
servicios Web XML evolucionen ofreciendo un modelo consistente y de propósito
general para añadir 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 gestión operacional como el routing de mensajes entre
múltiples servidores y la configuración dinámica de estos servidores también
forman parte de la arquitectura GXA, y se satisfacen por la especificación WSRouting y la especificación WS-Referral. A medida que la arquitectura GXA
crezca, se presentarán especificaciones para estas y otras necesidades.
En el futuro, algunos de los servicios Web XML más interesantes soportarán
aplicaciones que utilizarán 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 mecánico expusiesen sus calendarios
mediante este servicio Web XML, se podrían planificar citas en línea.
Es
fácil
imaginar
un
conjunto
completo
de
aplicaciones
que
podrían
ser
desarrolladas para analizar y agregar información importante y que la presentase
de varias formas; por ejemplo, podríamos tener una hoja de cálculo Excel que
integrase una imagen financiera completa (cotizaciones, cuentas bancarias,
préstamos, etc.). Si esta información está disponible mediante servicios web XML,
Excel puede actualizarla continuamente. Parte de esta información será gratuita y
parte podría requerir de una suscripción al servicio.
La mayoría de esta información está ya disponible en la Web, pero los servicios
Web XML harán que su acceso programático sea más fácil y fiable.
Exponer las aplicaciones existentes como servicios web XML permitirá a los usuarios
construir nuevas y más potentes aplicaciones que utilicen estos servicios como
bloques de construcción. Por ejemplo, un usuario podría desarrollar una aplicación
de compras para obtener automáticamente la información de precios de varios
fabricantes, que permitiera seleccionar un fabricante, enviar el pedido y a
continuación realizar seguimiento del envío hasta que sea recibido. La aplicación del
fabricante, además de exponer sus servicios en la Web, podría a su vez utilizar
servicios web XML para verificar el crédito del cliente, realizar un cargo en su
cuenta y realizar el envío con una empresa de transporte.