Aspectos basicos de los XML Web Services

Definición de XML Web Services
Los servicios XML Web Services son los elementos fundamentales en la evolución hacia la computación distribuida a través de Internet. Se están convirtiendo en la plataforma de integración de aplicaciones gracias a los estándares abiertos y al énfasis en la comunicación y colaboración entre personas y aplicaciones. Las aplicaciones se crean utilizando los servicios XML Web Services múltiples de origen distinto que funcionan conjuntamente, sin importar su ubicación o la forma en que se implementaron.

Existen tantas definiciones de los servicios XML Web Services como empresas que los diseñan. Sin embargo la idea general es:

Los servicios XML Web Services ofrecen funciones muy útiles a usuarios del medio Web ya que emplean un protocolo Web estándar que, en casi todos los casos, es SOAP.
Los servicios XML Web Services permiten describir sus interfaces con suficiente detalle para que el usuario diseñe una aplicación cliente que permita comunicarse con ellas. Esta descripción se proporciona normalmente en un documento XML denominado WSDL (lenguaje de descripción de servicios Web).
Los servicios XML Web Services se registran para que los futuros usuarios los encuentren fácilmente. Este registro se realiza a través de UDDI (descripción, descubrimiento e integración universales).
En este artículo comentaré estas tres tecnologías pero primero quiero explicar por qué son tan importantes los servicios XML Web Services.

Una de las principales ventajas de la arquitectura de los servicios XML Web Services es que permite que los programas escritos en lenguajes y plataformas diferentes puedan establecer comunicación entre sí de forma estándar. Seguro que los programadores que trabajan en esta industria desde hace tiempo se preguntarán:¿No era esto lo mismo que nos prometieron con CORBA y, anteriormente, con DCE? ¿Cómo es posible que los servicios XML Web Services sean diferentes?" La primera ventaja de los servicios XML Web Services es que SOAP es bastante menos complejo que sus antecesores, de modo que resulta más fácil que una implementación cumpla con los estándares de SOAP. Paul Kulchenko publica una lista de implementaciones SOAP en: http://www.soapware.org/directory/4/implementations (en inglés) que contiene al menos 79 entradas. Las grandes empresas de software diseñan implementaciones SOAP pero también existen otras muchas construidas y mantenidas por un único programador. Otra ventaja importante es que los servicios XML Web Services funcionan con protocolos Web estándar, como XML, HTTP y TCP/IP. Muchas empresas disponen ya de una infraestructura Web, así como de personal y conocimientos para mantenerla, de modo que el coste de entrada a estos servicios es mucho menor que con las tecnologías antecesoras.

He definido antes un servicio XML como un servicio de software que se muestra en Web a través de SOAP, se describe con un archivo WSDL y se registra en UDDI. La siguiente pregunta lógica es: "¿Qué se puede hacer con los servicios XML Web Services?" Los primeros servicios solían ser fuentes de información que podían incorporarse fácilmente en aplicaciones para cotizaciones bursátiles, previsión del tiempo, resultados deportivos, etc. Resulta fácil imaginar el tipo de aplicaciones que podían crearse para analizar e incluir información importante y presentarla en modos diferentes. Por ejemplo, en una hoja de cálculo de Microsoft® Excel en la que se resumiría la siguiente información: acciones, plan de pensiones, cuentas bancarias, préstamos, etc. Si esta información estuviera disponible a través de servicios XML Web Services, Excel podría actualizarla continuamente. Parte de dicha información sería gratuita y otra necesitaría que el usuario se subscribiera al servicio. La mayor parte de esta información está disponible ahora en Internet. Sin embargo, los servicios XML Web Services posibilitan que sea más fácil y fiable tener acceso a ella.

La exposición de aplicaciones existentes como servicios XML Web Services permitirá que los usuarios creen aplicaciones más potentes que utilicen estos servicios XML Web como elementos constituyentes. Por ejemplo, un usuario puede desarrollar una aplicación de compra para obtener automáticamente de varios fabricantes información sobre precios, permitir seleccionar un fabricante, enviar el pedido de compra y realizar un seguimiento hasta el momento de recibir el envío. Es posible que la aplicación del fabricante, además de exponer sus servicios en Web, utilice los servicios XML Web Services para comprobar el crédito del cliente, cargar el importe del envío en su cuenta y enviar el pedido a través de una empresa de transportes.

En el futuro, algunos de los servicios XML Web Services más interesantes admitirán aplicaciones que utilicen el medio Web para realizar tareas que no pueden realizarse actualmente. Por ejemplo, uno de los servicios que el proyecto Microsoft .NET My Services admitirá es un servicio de calendario. Así, si su dentista y mecánico expusieran sus calendarios mediante este servicio XML Web, usted podría concertar citas en línea desde su calendario para una limpieza dental y mantenimiento rutinario. Y es fácil imaginar los cientos de aplicaciones que podrían diseñarse cuando se tiene el conocimiento para programar el medio Web.

Para obtener más información sobre los servicios XML Web Services y las aplicaciones que le ayudan a crearlos, consulte la página principal de los servicios Web en MSDN.

SOAP
SOAP es el protocolo de comunicaciones para los servicios XML Web Services. Cuando se describe SOAP como un protocolo de comunicaciones, muchas personas piensan en DCOM o CORBA y se preguntan "¿Cómo realiza SOAP la activación de objetos?" o "¿Qué servicio de nombres utiliza SOAP?" Mientras es posible que una implementación SOAP incluya estos datos, el estándar SOAP no los especifica. SOAP define el formato XML para mensajes. Si tiene un fragmento creado correctamente en XML e incluido en un par de elementos SOAP, dispondrá ya de un mensaje SOAP. Sencillo, ¿verdad?

Existen otras partes en la especificación SOAP que describen cómo representar los datos de un programa como XML y cómo utilizar SOAP para realizar llamadas a procedimiento remoto (RPC). Estas partes opcionales de la especificación se utilizan para implementar aplicaciones estilo RPC en las que el cliente envía un mensaje SOAP que contiene una función a la que se puede llamar, además de los parámetros para pasar a la función. El servidor, por su parte, devuelve un mensaje con los resultados de la función ejecutada. Casi todas las implementaciones actuales de SOAP admiten aplicaciones RPC porque los programadores que trabajan con aplicaciones COM o CORBA conocen el estilo RPC. SOAP admite también aplicaciones con estilo de documento en las que los mensajes SOAP cubren un documento XML. Las aplicaciones SOAP con estilo de documento son muy flexibles. Muchos nuevos servicios XML Web Services aprovechan esta flexibilidad para diseñar servicios que sería difícil implementar mediante RPC.

La última parte opcional de la especificación SOAP define los contenidos de un mensaje HTTP que contiene un mensaje SOAP. Este enlace HTTP es importante porque casi todos los sistemas operativos actuales, y otros no tan actuales, admiten HTTP. Este enlace es opcional pero casi todas las implementaciones SOAP lo admiten porque es el único protocolo estandarizado para SOAP. Por esta razón, existe la falsa idea general de que SOAP necesita HTTP. Algunas implementaciones admiten MSMQ, series MQ, SMTP o TCP/IP. Sin embargo, la mayoría de los servicios XML Web Services utilizan HTTP porque es ubicuo. Dado que HTTP es un protocolo imprescindible para el medio Web, muchas empresas disponen de infraestructuras de redes que lo admiten y personal con conocimientos y experiencia para gestionarlo. En la actualidad ya se encuentran disponibles la seguridad, el control y la infraestructura de equilibrio de cargas para HTTP.

A la hora de empezar a trabajar con SOAP, es importante entender la diferencia entre la especificación SOAP y la variedad de implementaciones de esta especificación. Muchos programadores que utilizan SOAP no escriben mensajes SOAP directamente, sino que utilizan un SOAP Toolkit para crear y analizar mensajes SOAP. Generalmente, estos kits de herramientas traducen 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 el kit de herramientas de Apache traduce funciones de llamadas JAVA a SOAP. Los tipos de llamadas de función y los tipos de datos de los parámetros admitidos varían en cada implementación SOAP, de forma que es posible que una función que trabaja con un kit de herramientas no funcione con otro. Esto no es una limitación de SOAP, sino de la implementación específica que utilice en cada caso.

La característica más notable de SOAP es que se ha implementado en diferentes plataformas de hardware y software, lo que significa que puede utilizarse para enlazar sistemas dispares dentro y fuera de su empresa. En el pasado se realizaron muchos intentos para conseguir un protocolo de comunicaciones común que pudiera usarse en la integración de sistemas. Sin embargo, ningún intento se ha generalizado tanto como SOAP. ¿Por qué? Porque SOAP es más pequeño y sencillo de implementar que muchos de los protocolos anteriores. Por ejemplo, se tardaron años en implementar DCE y CORBA, de modo que sólo unas pocas implementaciones llegaron a comercializarse. Por su parte, SOAP utiliza analizadores XML y bibliotecas HTTP existentes para realizar la mayor parte del trabajo más complicado; por ello, una implementación SOAP puede estar terminada en cuestión de meses. Ésta es la razón por la que hay disponibles más de 70 implementaciones SOAP. No obstante, SOAP no consigue los mismos resultados que DCE o CORBA pero su sencillez y características posibilitan que esté disponible rápidamente.

La ubicuidad de HTTP y la sencillez de SOAP los convierte en una base perfecta para implementar servicios XML Web Services que pueden llamarse desde prácticamente cualquier entorno. Para obtener más información sobre SOAP, consulte la página principal de SOAP en MSDN.

Aspectos sobre la seguridad
Una de las primeras preguntas que se cuestiona un usuario nuevo es cómo protege SOAP la seguridad. En los primeros momentos de su desarrollo, SOAP era considerado como un protocolo basado en HTTP y, por tanto, se asumía que la seguridad de HTTP sería adecuada para SOAP. Además, existen miles de aplicaciones Web que se ejecutan actualmente utilizando la seguridad de HTTP. Por esta razón, el estándar SOAP actual supone que la seguridad es un problema de transporte y no comenta nada sobre los problemas de seguridad.

La seguridad empezó a ser un problema en el momento en que SOAP se convirtió en un protocolo más generalizado que se ejecutaba en múltiples medios de transporte. Por ejemplo, HTTP proporciona diferentes modos de autenticar qué usuario realiza una llamada SOAP. Pero, ¿cómo se propaga esa identidad al dirigirse el mensaje desde HTTP a un transporte SMTP? SOAP se diseñó como un protocolo de base; afortunadamente existen especificaciones en los textos para diseñar en SOAP que proporcionan más características de seguridad para servicios Web. El artículo sobre la especificación WS-Security define sistemas de cifrado completos y el artículo WS-License define técnicas que protegen la identidad de la persona que llama y aseguran que sólo usuarios autorizados puedan utilizar un servicio Web.

WSDL
WSDL es el acrónimo de Web Services Description Language (lenguaje de descripción de servicios Web). Para nuestros objetivos, se puede definir un archivo WSDL como un documento XML que describe un conjunto de mensajes SOAP y la forma en la que éstos se intercambian. En otras palabras, WSDL es a SOAP lo que IDL es a CORBA o a COM. WSDL es XML (es decir, se puede leer y modificar en gran parte de los casos) y es generado y utilizado por software.

Para comprobar el valor WSDL, imagine que desea llamar a un método SOAP que le proporciona uno de sus socios comerciales. Podría solicitarle algunos ejemplos de mensajes SOAP y escribir su propia aplicación para crear y utilizar mensajes que se mostraran de forma similar a los ejemplos. Esto, sin embargo, puede dar lugar a errores. Por ejemplo, si ve el Id. 2837 de un cliente, supondrá que es un número entero en lugar de una cadena. WSDL especifica qué debe contener un mensaje de solicitud y cómo se verá el mensaje de respuesta en una notación clara.

La notación que utiliza un archivo WSDL para describir formatos de mensaje se basa en el estándar XML. Esto significa que es un idioma de programación neutral y basado en estándares, lo cual es perfecto para describir interfaces de servicios XML Web Services que pueden abrirse desde una gran variedad de plataformas y lenguajes de programación. Además de describir el contenido de un mensaje, WSDL define el lugar en el que está disponible el servicio y qué protocolo de comunicaciones se utiliza para hablar al servicio. Esto significa que el archivo WSDL define todos los elementos necesarios para escribir un programa que pueda funcionar con un servicio XML Web. Existen varias herramientas disponibles para leer un archivo WSDL y generar el código necesario para establecer comunicación con un servicio XML Web. Algunas de las herramientas más útiles se encuentran en Microsoft Visual Studio® .NET.

Muchos de los actuales SOAP Toolkits incluyen herramientas para generar archivos WSDL desde interfaces de programas existentes. Sin embargo, hay pocas herramientas para escribir WSDL directamente y la compatibilidad para WSDL no es tan general como debería ser. No debería pasar mucho tiempo para que las herramientas que facilitan la creación de archivos WSDL, y posteriormente generan proxies y etiquetas como las herramientas COM IDL, formen parte de muchas implementaciones SOAP. En esa etapa, WSDL será el medio preferido para crear interfaces SOAP para los servicios XML Web Services.

Puede consultar una descripción excelente de WSDL y encontrar la especificación de WSDL en http://www.w3.org/TR/wsdl.

UDDI
UDDI (descripción, descubrimiento e integración universales) constituye las páginas amarillas de los servicios Web. Como en las páginas amarillas en papel, es fácil buscar una empresa que ofrece los servicios que necesita, leer acerca del servicio ofrecido y ponerse en contacto con una persona para solicitar más información. Por supuesto, puede ofrecer un servicio Web sin tener que registrarlo en UDDI, al igual que si, por ejemplo, abriera un negocio en el sótano de su casa y confiara en la publicidad del "boca a boca". Si quisiera ampliar sus expectativas en el mercado, necesitaría UDDI para que sus clientes lo encontraran.

Una entrada en un listín UDDI es un archivo XML que describe un negocio y los servicios que ofrece. Cada entrada tiene tres partes. Las "páginas blancas" describen los datos de la empresa, como nombre, dirección, información de contacto, etc. Las "páginas amarillas" incluyen las categorías industriales basadas en taxonomías estándares, como la NAICS (North American Industry Classification System) y la SIC (Standard Industrial Classification). Las "páginas verdes" describen la interfaz del servicio con información suficiente para que alguien escriba una aplicación para usar un servicio Web. Los servicios se definen por un documento UDDI denominado Type Model o tModel. En muchos casos, tModel contiene un archivo WSDL que describe una interfaz SOAP a un servicio XML Web; tModel es suficientemente flexible para describir prácticamente cualquier tipo de servicio.

El listín UDDI incluye también diferentes formas de búsqueda de servicios para que puede diseñar sus propias aplicaciones. Por ejemplo, puede buscar proveedores de un servicio en una ubicación concreta o negocios de un tipo determinado. El listín UDDI le proporcionará la información, personas de contacto, enlaces y datos técnicos para que evalúe los servicios que satisfacen sus necesidades.

UDDI permite buscar negocios de los que desee obtener servicios Web. Si conoce con quién quiere realizar negocios pero desconoce los servicios que ofrece el artículo WS-Inspection permite examinar una recopilación de los servicios XML Web Services ofrecidos en un servidor determinado para buscar los que satisfagan sus necesidades.

Si desea ver más información sobre UDDI, consulte http://www.uddi.org/about.html (en inglés).

Conclusión
Hemos comentado cómo hablar con los servicios XML Web Services (SOAP), cómo se describen estos servicios (WSDL) y cómo encontrarlos (UDDI). Éstas son las especificaciones básicas que proporcionan los pilares para la integración y agregación de una aplicación. A partir de aquí, las empresas construyen soluciones y obtienen resultados reales.

Si bien se han realizado muchos progresos para convertir los servicios XML Web Services en una realidad, queda mucho por hacer. Actualmente, las personas obtienen resultados satisfactorios de estos servicios pero quedan aspectos pendientes como la seguridad, la administración operativa, las transacciones, el intercambio seguro de mensajes, etc. La arquitectura global de los servicios XML Web Services ayudará a que estos servicios avancen al siguiente nivel proporcionándoles un modelo coherente y general para agregar nuevas capacidades avanzadas a estos servicios para que sean modulares y ampliables.

Los módulos para seguridad (WS-Security y WS-License) mencionados anteriormente forman parte de las especificaciones en la arquitectura global de servicios Web. Las necesidades de la administración operativa, como el enrutamiento de mensajes entre varios servidores y la configuración dinámica de éstos para procesar, forman también parte de la arquitectura global de los servicios Web, y los cumple WS-Routing y WS-Referral. A medida que crezca la arquitectura global de los servicios Web, se irán introduciendo especificaciones para éstas y otras necesidades.

Estadísticas Web

servido por Christian 1 comentario compártelo