Los servicios web XML son los componentes básicos de la informática distribuida en Internet. Los estándares abiertos y el enfoque en la comunicación y colaboración entre usuarios y aplicaciones han creado un entorno en el que los servicios web XML se convierten en la plataforma para la integración de aplicaciones. Las aplicaciones se construyen utilizando servicios web XML de múltiples fuentes diferentes que funcionan juntas independientemente de dónde se encuentren o cómo se implementen.
Hay tantas definiciones de servicios web XML como empresas que crean servicios web XML. Pero casi todas las definiciones tienen en común lo siguiente:
Los servicios web XML proporcionan funciones útiles a los usuarios web a través de protocolos web estándar. En la mayoría de los casos se utiliza el protocolo SOAP.
Los servicios web XML pueden especificar sus interfaces con gran detalle, lo que permite a los usuarios crear aplicaciones cliente para comunicarse con ellos. Esta descripción suele estar contenida en un documento XML denominado documento de lenguaje de descripción de servicios web (WSDL).
Los servicios web XML se registran para que los usuarios potenciales puedan encontrarlos fácilmente, lo que se logra a través de Descubrimiento, Descripción e Integración Universal (UDDI).
Este artículo presentará estas tres tecnologías, pero primero debemos explicar por qué debería prestar atención a los servicios web XML.
Una de las principales ventajas de la arquitectura de servicios web XML es que permite que una variedad de programas escritos en diferentes idiomas en diferentes plataformas se comuniquen entre sí de manera basada en estándares. Los usuarios que saben algo sobre esta industria pueden decir inmediatamente: "Espera un momento, ¿Corba y el DCE anterior no asumieron el mismo compromiso? ¿Cuál es la diferencia entre este y ellos? La diferencia más importante es: SOAP es mejor que antes". El enfoque es mucho más simple, por lo que existen muchas menos barreras para implementar SOAP que cumpla con los estándares. Paul Kulchenko proporciona una lista de implementaciones SOAP en http://www.soapware.org/directory/4/implementations (en inglés). Según el último recuento, la lista contenía 79 artículos. Como es de esperar, la mayoría de las principales empresas de software ofrecen implementaciones SOAP, pero también hay muchas implementaciones creadas y mantenidas por desarrolladores individuales. Otra ventaja importante de los servicios web XML sobre las soluciones anteriores es el uso de protocolos web estándar: XML, HTTP y TCP/IP. Muchas empresas ya han establecido una infraestructura web y sus empleados tienen el conocimiento y la experiencia para mantenerla. Por tanto, el coste de introducir servicios web XML es mucho menor que el de introducir tecnologías anteriores.
Definimos un Servicio Web XML como un servicio de software proporcionado en la Web vía SOAP, descrito mediante un archivo WSDL y registrado vía UDDI. Entonces, usted puede preguntarse: "¿Qué se puede hacer con los servicios web XML?" Los servicios web XML originales eran a menudo fuentes de información que podían incorporarse fácilmente a aplicaciones, como precios de acciones, pronósticos meteorológicos, resultados deportivos, etc. Es fácil imaginar toda una clase de aplicaciones que podrían crearse para analizar y resumir la información que le interesa y hacer que esa información esté disponible de diversas maneras; por ejemplo, podría utilizar una hoja de cálculo de Microsoft® Excel para resumir todos sus datos financieros; información: acciones, 401K, depósitos bancarios, préstamos, etc. Si esta información está disponible a través de los servicios web XML, Excel puede actualizarla continuamente. Parte de esta información es gratuita y otra puede requerir una suscripción para obtener el servicio correspondiente. Gran parte de esta información ya está disponible en la Web, pero los servicios web XML pueden hacer que el acceso mediante programación sea más fácil y confiable.
Las aplicaciones existentes están disponibles como servicios web XML y se pueden crear aplicaciones nuevas y más potentes utilizando servicios web XML como bloques de construcción. Por ejemplo, un usuario puede desarrollar una aplicación de compras para obtener automáticamente información de precios de diferentes proveedores, permitiéndole seleccionar un proveedor, enviar un pedido y luego rastrear el envío de bienes hasta que se reciban. Además de brindar servicios en la Web, la aplicación del proveedor también puede utilizar el Servicio Web XML para verificar el crédito del cliente, cobrar pagos y manejar procedimientos de transporte con compañías de transporte.
En el futuro, algunas de las aplicaciones basadas en servicios web XML más interesantes podrán aprovechar la web para realizar tareas que actualmente son imposibles. Por ejemplo, el servicio de calendario es uno de los servicios que será compatible con el proyecto Microsoft .NET My Services (inglés). Si sus dentistas y mecánicos brindan sus horarios a través de este Servicio Web XML, puede programar citas con ellos a través de la Web si lo prefiere, también pueden programar fechas de limpiezas y mantenimiento de rutina directamente en su calendario; Es fácil imaginar que si pudieras programar la Web, podrías crear cientos de aplicaciones.
Para obtener más información sobre los servicios web XML y las aplicaciones que puede crear, consulte la página de inicio de los servicios web MSDN (inglés).
SOAP
SOAP es el protocolo de comunicación del servicio web XML. Al describir SOAP como un protocolo de comunicaciones, la mayoría de la gente piensa en DCOM o CORBA y hace preguntas como "¿Cómo activa SOAP los objetos o "¿Qué servicio de nombres utiliza SOAP?" Aunque las implementaciones SOAP pueden incluir estos elementos, el estándar SOAP no los especifica. SOAP Una especificación que define el formato XML de los mensajes; esta es una parte obligatoria de la especificación. Un segmento XML bien formado contenido dentro de un par de elementos SOAP es un mensaje SOAP. ¿No es esto simple?
Otras partes de la especificación SOAP describen cómo representar datos de programa como XML y cómo usar SOAP para llamadas a procedimientos remotos (RPC). Estas partes opcionales de la especificación se utilizan para implementar aplicaciones de estilo RPC, donde el cliente emitirá un mensaje SOAP (que contiene una función invocable y los parámetros que se pasarán a la función), y el servidor devolverá un mensaje que contiene los resultados. de la ejecución de la función. Actualmente, la mayoría de las implementaciones SOAP admiten aplicaciones RPC porque los programadores acostumbrados a desarrollar aplicaciones COM o CORBA están familiarizados con el formato RPC. SOAP también admite aplicaciones de estilo documento, en las que un mensaje SOAP es simplemente un contenedor alrededor de un documento XML. Las aplicaciones SOAP basadas en documentos son muy flexibles y muchos servicios web XML nuevos aprovechan esta característica para crear servicios que son difíciles de implementar utilizando RPC.
La última parte opcional de la especificación SOAP define el estilo de los mensajes HTTP que contienen mensajes SOAP. Este enlace HTTP es importante porque casi todos los sistemas operativos actuales (y muchos sistemas operativos anteriores) admiten HTTP. Aunque es opcional, el enlace HTTP es compatible con casi todas las implementaciones SOAP porque es el único protocolo estándar para SOAP. Por esta razón, la gente suele creer erróneamente que SOAP debe utilizar HTTP. De hecho, algunas implementaciones también admiten el transporte MSMQ, MQ Series, SMTP o TCP/IP, pero debido a que HTTP es tan omnipresente, casi todos los servicios web XML actuales lo utilizan. Dado que HTTP es el protocolo central de la Web, la infraestructura de red de la mayoría de las organizaciones admite HTTP y los empleados ya saben cómo administrarlo. Hoy, se ha establecido la infraestructura para la seguridad, el monitoreo y el equilibrio de carga de HTTP.
Al empezar a utilizar SOAP, lo más confuso es la diferencia entre la especificación SOAP y sus múltiples implementaciones. La mayoría de los usuarios de SOAP no escriben mensajes SOAP directamente, sino que utilizan kits de herramientas SOAP para crear y analizar mensajes SOAP. Estos kits de herramientas suelen convertir llamadas a funciones de un idioma en mensajes SOAP. Por ejemplo, Microsoft SOAP Toolkit 2.0 convierte llamadas a funciones COM a SOAP y Apache Toolkit convierte llamadas a funciones JAVA a SOAP. Los tipos de llamadas a funciones y los tipos de datos de parámetros admitidos varían con cada implementación SOAP, por lo que una función que funciona para un kit de herramientas puede no funcionar para otro. Esto no es una limitación de SOAP, sino de la implementación específica utilizada.
Con diferencia, la característica más convincente de SOAP es que puede implementarse en muchas plataformas de software y hardware diferentes. Esto significa que SOAP se puede utilizar para vincular sistemas dispares dentro y fuera de la empresa. En el pasado se han probado varios enfoques para encontrar un protocolo de comunicaciones común que pueda usarse para la integración del sistema, pero ninguno de ellos ha obtenido la aceptación generalizada que tiene SOAP. ¿Por qué? Porque SOAP es más pequeño y más fácil de implementar que muchos protocolos anteriores. Por ejemplo, DCE y CORBA tardaron años en implementarse, por lo que solo se han publicado unas pocas implementaciones. SOAP puede aprovechar los analizadores XML y las bibliotecas HTTP existentes para realizar la mayor parte del trabajo duro, por lo que una implementación SOAP se puede completar en cuestión de meses. Es por eso que ahora existen más de 70 implementaciones SOAP. Por supuesto, SOAP no tiene todas las funciones de DCE o CORBA. Aunque las funciones son reducidas, SOAP es más fácil de aplicar porque su complejidad se reduce considerablemente.
La popularidad de HTTP y la simplicidad de SOAP le permiten llamarlos desde casi cualquier entorno, lo que los convierte en una base ideal para los servicios web XML. Para obtener más información sobre SOAP, consulte la página de inicio de MSDN SOAP (inglés).
¿Qué tan seguro es?
A menudo, la primera pregunta que hacen los usuarios nuevos en SOAP es cómo SOAP resuelve los problemas de seguridad. En sus primeras etapas de desarrollo, SOAP se consideraba un protocolo basado en HTTP, por lo que la seguridad de HTTP se consideraba suficiente para SOAP. Después de todo, actualmente hay miles de aplicaciones web que utilizan seguridad HTTP, por lo que esto es suficiente para SOAP. Por lo tanto, el estándar SOAP actual asume que la seguridad es una cuestión de transporte y no se trata como una cuestión de seguridad.
A medida que SOAP se expande hacia un protocolo más general y se ejecuta en numerosos transportes, los problemas de seguridad se vuelven más prominentes. Por ejemplo, HTTP proporciona varias formas de autenticar a los usuarios que realizan llamadas SOAP, pero ¿cómo se propaga esa identidad cuando los mensajes se enrutan desde HTTP al transporte SMTP? SOAP fue diseñado como un protocolo básico, por lo que afortunadamente existen especificaciones para proporcionar características de seguridad adicionales para los servicios web basados en SOAP. La especificación WS-Security (inglés) define un sistema de cifrado completo y la especificación WS-License (inglés) define la tecnología correspondiente para garantizar la identidad de la persona que llama y garantizar que solo los usuarios autorizados puedan utilizar los servicios web.
WSDL
WSDL (Lenguaje de descripción de servicios web) significa Lenguaje de descripción de servicios web. Para los fines de este artículo, podemos considerar un archivo WSDL como un documento XML que describe un conjunto de mensajes SOAP y cómo intercambiarlos. En otras palabras, WSDL es para SOAP lo que IDL es para CORBA o COM. Debido a que WSDL es un documento XML, es fácil de leer y editar, pero en la mayoría de los casos lo genera y utiliza el software.
Para ver los valores del WSDL, imagine que desea llamar a un método SOAP proporcionado por uno de sus socios comerciales. Puede solicitar algunos mensajes SOAP de muestra y luego escribir su aplicación para generar y usar mensajes similares a los de muestra, pero es fácil cometer errores. Por ejemplo, es posible que vea un ID de cliente de 2837 y suponga que es un número entero, cuando en realidad es una cadena. WSDL especifica mediante una notación explícita qué debe contener el mensaje de solicitud y cómo debe verse el mensaje de respuesta.
La notación utilizada por los archivos WSDL para describir formatos de mensajes se basa en el estándar XML Schema, lo que significa que es independiente del lenguaje de programación y está basado en estándares, lo que lo hace adecuado para describir servicios web XML a los que se puede acceder desde diferentes plataformas y en diferentes programas. Idiomas. Además de describir el contenido del mensaje, WSDL también define la ubicación del servicio y qué protocolo de comunicación se utiliza para comunicarse con el servicio. Es decir, el archivo WSDL define todo lo necesario para escribir un programa que utilice servicios web XML. Existen varias herramientas que pueden leer archivos WSDL y generar el código necesario para comunicarse con servicios web XML. Algunas de las herramientas más poderosas se pueden encontrar en Microsoft Visual Studio® .NET.
Actualmente, muchos kits de herramientas SOAP incluyen herramientas para generar archivos WSDL a partir de interfaces de programas existentes, pero hay pocas herramientas para escribir WSDL directamente y el soporte de herramientas para WSDL está incompleto. Pero pronto habrá herramientas para escribir archivos WSDL, seguidas de herramientas para generar proxies y stubs (muy similares a las herramientas COM IDL), y estas herramientas pasarán a formar parte de la mayoría de las implementaciones SOAP. Hasta entonces, WSDL se convertirá en el método preferido para crear interfaces SOAP para servicios web XML.
Hay una muy buena descripción de WSDL aquí (en inglés), y también puede encontrar la especificación WSDL en http://www.w3.org/TR/wsdl (en inglés).
UDDI
Universal Discovery, Descripción e Integración (UDDI) son las páginas amarillas de los servicios web. Al igual que las tradicionales Páginas Amarillas, puedes buscar empresas que ofrezcan los servicios que necesitas, leer para conocer los servicios ofrecidos y luego contactar a alguien para obtener más información. Por supuesto, puede proporcionar servicios web sin registrarlos en UDDI, lo cual es como administrar un negocio en su sótano y confiar en el boca a boca, pero si desea expandir su mercado, necesita UDDI para que sus clientes puedan descubrirlo; clientes.
Las entradas del directorio UDDI son archivos XML que describen los servicios y servicios proporcionados. Una entrada de directorio UDDI consta de tres partes. Las "Páginas Blancas" presentan empresas que prestan servicios: nombre, dirección, información de contacto, etc.; las "Páginas Amarillas" incluyen categorías industriales basadas en clasificaciones estándar (como el Sistema de Clasificación Industrial de América del Norte y la Clasificación Industrial Estándar) que proporcionan información detallada; información Acceda a la interfaz del servicio para que los usuarios puedan escribir aplicaciones para consumir el servicio web. La definición de un servicio se logra a través de un documento UDDI llamado modelo de tipo (o tModel). En la mayoría de los casos, tModel contiene un archivo WSDL que describe la interfaz SOAP para acceder al servicio web XML, pero tModel es muy flexible y puede describir casi cualquier tipo de servicio.
El directorio UDDI también contiene varios métodos para buscar los servicios necesarios para crear su aplicación. Por ejemplo, puede buscar proveedores de servicios en una ubicación geográfica específica o buscar un tipo de negocio específico. A continuación, el directorio UDDI le proporcionará información, datos de contacto, enlaces y datos técnicos para que pueda identificar los servicios que se adaptan a sus necesidades.
UDDI le permite encontrar empresas que brinden los servicios web que necesita. ¿Qué haces si ya sabes con quién quieres hacer negocios, pero aún no sabes qué más te puede ofrecer? La especificación WS-Inspection (en inglés) le permite explorar la colección de servicios web XML disponibles en un servidor específico para encontrar el servicio que necesita.
Para obtener más información sobre UDDI, visite http://www.uddi.org/about.html (en inglés).
Otro contenido
Hasta ahora, hemos analizado cómo comunicarse con los servicios web XML (SOAP), cómo se describen los servicios web XML (WSDL) y cómo encontrar servicios web XML (UDDI). Estos forman un conjunto básico de especificaciones que proporcionan la base para la integración y agregación de aplicaciones. A partir de estas especificaciones básicas, las empresas pueden crear soluciones prácticas y beneficiarse de ellas.
Hemos trabajado mucho para implementar los servicios web XML, pero todavía queda mucho trabajo por hacer. Hoy en día, la gente ha logrado el éxito utilizando los servicios web XML, pero para los desarrolladores todavía hay muchos vínculos que mejorar. Por ejemplo, seguridad, gestión de operaciones, procesamiento de transacciones y mensajería confiable. La Arquitectura Global de Servicios Web XML ayudará a los Servicios Web XML a ingresar a la siguiente etapa de evolución al proporcionar un modelo común y consistente para agregar nuevas capacidades avanzadas a los Servicios Web XML de manera modular y extensible.
Los módulos de seguridad mencionados anteriormente (WS-Security [inglés] y WS-License [inglés]) son parte de la especificación Global Web Services Architecture. Las necesidades de gestión operativa (como enrutar mensajes entre múltiples servidores y configurar dinámicamente esos servidores para su procesamiento) también son parte de la Arquitectura de Servicios Web Global a través de la especificación WS-Routing (inglés) y la especificación WS-Referral (inglés) para lograr. A medida que evolucione la arquitectura global de servicios web, se introducirán especificaciones que aborden estas y otras necesidades.