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.
