Conceptos básicos de servicios web XML
Roger Wolter
Microsoft Corporation
Diciembre de 2001
Resumen: Información general sobre el valor de los servicios web XML para desarrolladores, con introducción a SOAP, WSDL y UDDI. (6 páginas impresas)
Contenido
¿Qué es un servicio web XML?
SOAP
WSDL
UDDI
¿Qué queda?
¿Qué es un servicio web XML?
Los servicios web XML son los bloques de creación fundamentales en el traslado a la informática distribuida en Internet. Los estándares abiertos y el enfoque en la comunicación y la colaboración entre personas y aplicaciones han creado un entorno en el que los servicios web XML se están convirtiendo en la plataforma para la integración de aplicaciones. Las aplicaciones se construyen mediante varios servicios web XML de varios orígenes que funcionan conjuntamente independientemente de dónde residen o cómo se implementaron.
Probablemente hay tantas definiciones de servicio web XML como hay empresas que las crean, pero casi todas las definiciones tienen estas cosas en común:
- Los servicios web XML exponen una funcionalidad útil a los usuarios web a través de un protocolo web estándar. En la mayoría de los casos, el protocolo utilizado es SOAP.
- Los servicios web XML proporcionan una manera de describir sus interfaces con suficiente detalle para permitir que un usuario compile una aplicación cliente para comunicarse con ellos. Normalmente, esta descripción se proporciona en un documento XML denominado documento WSDL (Lenguaje de descripción de servicios web).
- Los servicios web XML se registran para que los usuarios potenciales puedan encontrarlos fácilmente. Esto se hace con la descripción e integración de la detección universal (UDDI).
Trataré las tres tecnologías de este artículo, pero primero quiero explicar por qué debe preocuparse por los servicios web XML.
Una de las principales ventajas de la arquitectura de servicios web XML es que permite que los programas escritos en diferentes lenguajes en distintas plataformas se comuniquen entre sí de forma basada en estándares. Los que han estado alrededor de la industria un rato ahora dicen: "¡Espere un minuto! ¿No oí esas mismas promesas de CORBA y antes de esa DCE? ¿Cómo es esto diferente?" La primera diferencia es que SOAP es significativamente menos complejo que los enfoques anteriores, por lo que la barrera de entrada para una implementación soap compatible con estándares es significativamente menor. Paul Kulchenko mantiene una lista de implementaciones SOAP en: http://www.soapware.org/directory/4/implementations que en el último recuento contenía 79 entradas. Encontrará implementaciones soap de la mayoría de las grandes empresas de software, como cabría esperar, pero también encontrará muchas implementaciones creadas y mantenidas por un único desarrollador. La otra ventaja significativa que los servicios web XML tienen sobre los esfuerzos anteriores es que funcionan con protocolos web estándar: XML, HTTP y TCP/IP. Un número significativo de empresas ya tienen una infraestructura web y personas con conocimientos y experiencia en el mantenimiento, por lo que, de nuevo, el costo de entrada para los servicios web XML es significativamente menor que las tecnologías anteriores.
Hemos definido un servicio web XML como un servicio de software expuesto en la Web a través de SOAP, descrito con un archivo WSDL y registrado en UDDI. La siguiente pregunta lógica es. "¿Qué puedo hacer con los servicios web XML?" Los primeros servicios web XML tienden a ser orígenes de información que se pueden incorporar fácilmente a aplicaciones: cotizaciones de cotizaciones, pronósticos meteorológicos, puntuaciones deportivas, etc. Es fácil imaginar una clase completa de aplicaciones que se pueden crear para analizar y agregar la información que le interesa y presentarla de varias maneras; por ejemplo, puede tener una hoja de cálculo de Microsoft® Excel que resuma toda la imagen financiera: acciones, 401K, cuentas bancarias, préstamos, etc. Si esta información está disponible a través de servicios web XML, Excel puede actualizarla continuamente. Parte de esta información será gratuita y algunas podrían requerir una suscripción al servicio. La mayoría de esta información está disponible ahora en la Web, pero los servicios web XML harán que el acceso mediante programación sea más fácil y confiable.
La exposición de aplicaciones existentes como servicios web XML permitirá a los usuarios crear aplicaciones nuevas y más eficaces que usen servicios web XML como bloques de creación. Por ejemplo, un usuario podría desarrollar una aplicación de compra para obtener automáticamente información de precios de una variedad de proveedores, permitir al usuario seleccionar un proveedor, enviar el pedido y, a continuación, realizar un seguimiento del envío hasta que se reciba. La aplicación de proveedor, además de exponer sus servicios en la Web, podría usar a su vez servicios web XML para comprobar el crédito del cliente, cobrar la cuenta del cliente y configurar el envío con una empresa de envío.
En el futuro, algunos de los servicios web XML más interesantes admitirán aplicaciones que usan la Web para hacer cosas que no se pueden hacer hoy en día. Por ejemplo, uno de los servicios que los servicios web XML harían posible es un servicio de calendario. Si su dentista y mecánico exponen sus calendarios a través de este servicio web XML, puede programar citas con ellos en línea o pueden programar citas para limpieza y mantenimiento rutinario directamente en su calendario si lo desea. Con un poco de imaginación, puede imaginar cientos de aplicaciones que se pueden compilar una vez que tiene la capacidad de programar la Web.
Para obtener más información sobre los servicios web XML y las aplicaciones que le ayudarán a compilar, consulte el Centro para desarrolladores de servicios web XML de MSDN.
SOAP
Soap es el protocolo de comunicaciones para los servicios web XML. Cuando SOAP se describe como un protocolo de comunicaciones, la mayoría de las personas piensan en DCOM o CORBA y empiezan a preguntar cosas como "¿ Cómo hace SOAP la activación de objetos?" o "¿Qué servicio de nomenclatura usa SOAP?" Aunque una implementación de SOAP probablemente incluirá estas cosas, el estándar SOAP no los especifica. SOAP es una especificación que define el formato XML para los mensajes y que se trata de ella para las partes necesarias de la especificación. Si tiene un fragmento XML bien formado entre un par de elementos SOAP, tiene un mensaje SOAP. ¿Simple no es así?
Hay otras partes de la especificación SOAP que describen cómo representar datos de programa como XML y cómo usar SOAP para realizar llamadas a procedimientos remotos. Estas partes opcionales de la especificación se usan para implementar aplicaciones de estilo RPC en las que 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 función ejecutada. La mayoría de las implementaciones actuales de SOAP admiten aplicaciones RPC porque los programadores que se usan para realizar aplicaciones COM o CORBA comprenden el estilo RPC. SOAP también admite aplicaciones de estilo de documento en las que el mensaje SOAP es simplemente un contenedor alrededor de un documento XML. Las aplicaciones SOAP de estilo documento son muy flexibles y muchos servicios web XML nuevos aprovechan esta flexibilidad para crear servicios que serían difíciles de implementar mediante RPC.
La última parte opcional de la especificación SOAP define el aspecto de un mensaje HTTP que contiene un mensaje SOAP. Este enlace HTTP es importante porque EL HTTP es compatible con casi todos los sistemas operativos actuales (y muchos del sistema operativo no tan actual). El enlace HTTP es opcional, pero casi todas las implementaciones soap lo admiten porque es el único protocolo estandarizado para SOAP. Por este motivo, hay una idea errónea común de que SOAP requiere HTTP. Algunas implementaciones admiten transportes MSMQ, MQ Series, SMTP o TCP/IP, pero casi todos los servicios web XML actuales usan HTTP porque es omnipresente. Dado que HTTP es un protocolo básico de la Web, la mayoría de las organizaciones tienen una infraestructura de red que admite HTTP y personas que entienden cómo administrarlo ya. La infraestructura de seguridad, supervisión y equilibrio de carga para HTTP está disponible en la actualidad.
Una fuente importante de confusión al empezar a trabajar con SOAP es la diferencia entre la especificación SOAP y las muchas implementaciones de la especificación SOAP. La mayoría de las personas que usan SOAP no escriben mensajes SOAP directamente, sino que usan un kit de herramientas SOAP para crear y analizar los mensajes SOAP. Estos kits de herramientas suelen traducir llamadas de función de algún tipo de lenguaje a un mensaje SOAP. Por ejemplo, Microsoft SOAP Toolkit 2.0 traduce llamadas de función COM a SOAP y Apache Toolkit traduce las llamadas de función java a SOAP. Los tipos de llamadas de función y los tipos de datos de los parámetros admitidos varían con cada implementación soap para que una función que funcione con un kit de herramientas no funcione con otro. Esto no es una limitación de SOAP, sino de la implementación concreta que está usando.
En gran medida, la característica más atractiva de SOAP es que se ha implementado en muchas plataformas de hardware y software diferentes. Esto significa que SOAP se puede usar para vincular sistemas dispares dentro y sin su organización. Muchos intentos han sido realizados en el pasado con un protocolo de comunicaciones común que se podría usar para la integración de sistemas, pero ninguno de ellos ha tenido la adopción generalizada de SOAP. ¿Por qué ocurre esto? Dado que SOAP es mucho más pequeño y más sencillo de implementar que muchos de los protocolos anteriores. DCE y CORBA, por ejemplo, tardaron años en implementarse, por lo que solo se publicaron algunas implementaciones. Sin embargo, SOAP puede usar analizadores XML y bibliotecas HTTP existentes para realizar la mayor parte del trabajo duro, por lo que se puede completar una implementación de SOAP en cuestión de meses. Este es el motivo por el que hay más de 70 implementaciones soap disponibles. SOAP obviamente no hace todo lo que hace DCE o CORBA, pero la falta de complejidad a cambio de características es lo que hace que SOAP esté tan disponible.
La ubicuidad de HTTP y la simplicidad de SOAP las convierten en una base ideal para implementar servicios web XML a los que se puede llamar desde casi cualquier entorno. Para obtener más información sobre SOAP, consulte la página principal de SOAP de MSDN.
¿Qué hay de la seguridad?
Una de las primeras preguntas que los recién llegados a SOAP hacen es cómo se ocupa SOAP de la seguridad. Al principio de su desarrollo, SOAP se vio como un protocolo basado en HTTP, por lo que se supone que la seguridad HTTP sería adecuada para SOAP. Después de todo, hay miles de aplicaciones web que se ejecutan hoy en día con seguridad HTTP, por lo que seguramente esto es adecuado para SOAP. Por este motivo, el estándar SOAP actual supone que la seguridad es un problema de transporte y es silencioso en los problemas de seguridad.
Cuando SOAP se expandió para convertirse en un protocolo de uso más general que se ejecuta sobre una serie de transportes, la seguridad se convirtió en un problema mayor. Por ejemplo, HTTP proporciona varias maneras de autenticar qué usuario realiza una llamada SOAP, pero ¿cómo se propaga esa identidad cuando el mensaje se enruta desde HTTP a un transporte SMTP? SOAP se diseñó como un protocolo de bloque de creación, por lo que afortunadamente, ya hay especificaciones en las obras para compilar en SOAP para proporcionar características de seguridad adicionales para los servicios web. La especificación WS-Security define un sistema de cifrado completo.
WSDL
WSDL (a menudo pronunciado whiz-dull) significa Lenguaje de descripción de servicios web. Para nuestros fines, podemos decir que un archivo WSDL es un documento XML que describe un conjunto de mensajes SOAP y cómo se intercambian los mensajes. En otras palabras, WSDL es para SOAP qué IDL es corba o COM. Dado que WSDL es XML, es legible y editable, pero en la mayoría de los casos, se genera y consume por software.
Para ver el valor de WSDL, imagine que quiere empezar a llamar a un método SOAP proporcionado por uno de sus socios comerciales. Puede pedirle algunos mensajes SOAP de ejemplo y escribir la aplicación para generar y consumir mensajes que parecen los ejemplos, pero esto puede ser propenso a errores. Por ejemplo, podría ver un identificador de cliente de 2837 y suponer que es un entero cuando, de hecho, es una cadena. WSDL especifica qué debe contener un mensaje de solicitud y cuál será el aspecto del mensaje de respuesta en notación inequívoca.
La notación que usa un archivo WSDL para describir los formatos de mensaje se basa en el estándar de esquema XML, lo que significa que se basa tanto en lenguaje de programación neutro como en estándares, lo que hace que sea adecuado para describir interfaces de servicios web XML que son accesibles desde una amplia variedad de plataformas y lenguajes de programación. Además de describir el contenido del mensaje, WSDL define dónde está disponible el servicio y qué protocolo de comunicaciones se usa para comunicarse con el servicio. Esto significa que el archivo WSDL define todo lo necesario para escribir un programa para trabajar con un servicio web XML. Hay varias herramientas disponibles para leer un archivo WSDL y generar el código necesario para comunicarse con un servicio web XML. Algunas de las herramientas más capaces de estas herramientas están en Microsoft Visual Studio® .NET.
Muchos kits de herramientas soap actuales incluyen herramientas para generar archivos WSDL a partir de interfaces de programa existentes, pero hay pocas herramientas para escribir WSDL directamente y la compatibilidad con herramientas para WSDL no es tan completa como debería ser. No debe pasar mucho tiempo antes de que las herramientas creen archivos WSDL y, a continuación, generen proxies y códigos auxiliares, como las herramientas DE IDL COM, formarán parte de la mayoría de las implementaciones de SOAP. En ese momento, WSDL se convertirá en la manera preferida de crear interfaces SOAP para servicios web XML.
Está disponible una excelente descripción de WSDL y puede encontrar la especificación WSDL en http://www.w3.org/TR/wsdl.
UDDI
Descripción e integración de la detección universal es las páginas amarillas de los servicios web. Al igual que con las páginas amarillas tradicionales, puede buscar una empresa que ofrezca los servicios que necesita, leer sobre el servicio ofrecido y ponerse en contacto con alguien para obtener más información. Por supuesto, puedes ofrecer un servicio web sin registrarlo en UDDI, al igual que puedes abrir un negocio en tu sótano y confiar en publicidad de palabras de boca, pero si quieres llegar a un mercado significativo, necesitas UDDI para que tus clientes puedan encontrarte.
Una entrada de directorio UDDI es un archivo XML que describe una empresa y los servicios que ofrece. Hay tres partes en una entrada en el directorio UDDI. Las "páginas blancas" describen la empresa que ofrece el servicio: nombre, dirección, contactos, etc. Las "páginas amarillas" incluyen categorías industriales basadas en taxonomías estándar, como el sistema de clasificación industrial de Norteamérica y la clasificación industrial estándar. Las "páginas verdes" describen la interfaz del servicio con suficiente detalle para que alguien escriba una aplicación para usar el servicio web. La forma en que se definen los servicios es a través de un documento UDDI denominado Type Model o tModel. En muchos casos, el tModel contiene un archivo WSDL que describe una interfaz SOAP para un servicio web XML, pero tModel es lo suficientemente flexible como para describir casi cualquier tipo de servicio.
El directorio UDDI también incluye varias maneras de buscar los servicios que necesita para compilar las aplicaciones. Por ejemplo, puede buscar proveedores de un servicio en una ubicación geográfica especificada o para empresas de un tipo especificado. A continuación, el directorio UDDI proporcionará información, contactos, vínculos y datos técnicos para permitirle evaluar qué servicios cumplen sus requisitos.
UDDI le permite encontrar empresas de las que es posible que desee obtener servicios web. ¿Qué ocurre si ya sabe con quién desea hacer negocios, pero no sabe con qué servicios se ofrecen? La especificación WS-Inspection permite examinar una colección de servicios web XML ofrecidos en un servidor específico para encontrar cuáles pueden satisfacer sus necesidades.
Puede encontrar más información sobre udDI en http://www.uddi.org/about.html.
¿Qué queda?
Hasta ahora hemos hablado de cómo hablar con servicios web XML (SOAP), cómo se describen los servicios web XML (WSDL) y cómo buscar servicios web XML (UDDI). Estos constituyen un conjunto de especificaciones de línea base que proporcionan la base para la integración y agregación de aplicaciones. A partir de estas especificaciones de línea base, las empresas están creando soluciones reales y obteniendo valor real de ellas.
Aunque se ha realizado mucho trabajo para hacer que los servicios web XML sean una realidad, se necesita más. Hoy en día, las personas tienen éxito con los servicios web XML, pero todavía hay cosas que quedan como ejercicio para el desarrollador®, por ejemplo, seguridad, administración operativa, transacciones, mensajería confiable. La arquitectura global de servicios web XML ayudará a llevar los servicios web XML al siguiente nivel proporcionando un modelo coherente de uso general para agregar nuevas funcionalidades avanzadas a los servicios web XML, que son modulares y extensibles.
WS-Security es una de las especificaciones de la arquitectura de servicios web globales. Las necesidades de administración operativa, como el enrutamiento de mensajes entre muchos servidores y la configuración dinámica de esos servidores para su procesamiento, también forman parte de la arquitectura de servicios web globales y se cumplen mediante la especificación WS-Routing y la especificación WS-Referral. A medida que crece la arquitectura de servicios web globales, se introducirán especificaciones para estas y otras necesidades.
Puede encontrar más información en la Arquitectura global de servicios web XML.