Introducin a los servicios web Toda la informacin disponible para cualquier persona, en cualquier lugar, a travs de cualquier dispositivo.

Esta frase acua quizs el sueo de todos los que de una u otra forma se relacionan con las tecnologas de la informacin, partiendo desde una gran compaa tecnolgica hasta un simple usuario de una planilla Excel. La pregunta es: Ser esto posible? A mediado de la dcada de los 90 y con la aparicin de Internet y su posterior masificacin a niveles jams pensados, ha existido siempre la necesidad e inquietud por parte de las empresas desarrolladoras de software de buscar o contar con la manera de lograr la integracin entre sistemas heterogneos, cuando hablo de sistemas heterogneos me refiero tanto al software como al hardware. Para tal efecto muchas compaas fueron creando de forma individual la mejor manera de lograr esta integracin. Muchas empresas comenzaron una loca carrera para generar la mejor tecnologa integradora de sistemas, pero a medida que la competencia se hacia cada vez ms fuerte, la integracin se hacia cada vez ms difcil. Debido a la gran masificacin de Internet a niveles insospechables y al gran impacto causado por las tecnologas de la informacin en las ultimas dos dcadas del siglo pasado, la manera de hacer negocios y la comunicacin entre las personas y las empresas cambi de una manera rotunda. Bajo este contexto se haca cada vez mayor la necesidad de integrar y compartir informacin entre distintas plataformas de software y hardware. Las empresas se percataron que era imposible crear una plataforma integrado de forma individual, as que decidieron atacar el problema de raz. Para esto decidieron que en vez de crear la mejor plataforma integradora, era mejor buscar un leguaje comn de intercambio de informacin aprovechando los estndares existentes en el mercado. Bajo este contexto nacen los Servicios Web basados en XML, los cuales son el objeto de estudio del presente manual. OBJETIVOS Conocer y entender el significado y alcance le los Servicios Web XML. Esto implica entender el contexto global en el cual se desarrollaron los Servicios Web para as conseguir de manera prctica la adopcin e implementacin de dicha tecnologa, tambin conocer sus principales ventajas as como sus limitaciones desde un punto de vista de una tecnologa que esta en continuo desarrollo. Dimensionar los nuevos cambios de paradigmas informticos producto de la implementacin de Servicios Web. Esto quiere decir poder dimensionar que esta tecnologa viene a cambiar la forma en que se comunicaban las distintas aplicaciones y la forma en que se accede a la informacin que reside en distintas plataformas y aplicaciones desde diversos tipos de equipos y dispositivo de comunicacin.

Ampliar el conocimiento de todas las tecnologas asociadas a los Servicios Web.De manera general o detallada conocer las tecnologas asociadas a Servicios Web. Ya que de alguna manera, ms temprano que tarde, nos encontraremos inmersos en ellas. Dejar un documento escrito que sirva de base para los futuros estudiantes que se interesen en descubrir nuevas tecnologa. La intencin del presente documento no es solo la de explicar el contexto de los Servicios Web, si no tambin transmitir al lector un numero de nuevos conceptos y tecnologas que en la actualidad estn en pleno desarrollo y en adopcin por diversas empresas. Todo lo anterior pretende incentivar al lector a que investigue y descubra nuevas herramientas con las cuales logre estar un grado por encima del resto en lo que a informtica se refiere. Una visin general I Web Services y la evolucin hacia la Economa Global Las aplicaciones web actuales ya no son suficientes. El modelo actual de negocio electrnico no facilita la integracin de las aplicaciones de Internet con el resto de software de las empresas. Si las compaas quieren extraer el mximo beneficio de Internet, los sitios web deben evolucionar. Este es el contexto en el que surgen los web services. Los web services son componentes software que permiten a los usuarios usar aplicaciones de negocio que comparten datos con otros programas modulares, va Internet. Son aplicaciones independientes de la plataforma que pueden ser fcilmente publicadas, localizadas e invocadas mediante protocolos web estndar, como XML, SOAP, UDDI o WSDL. El objetivo final es la creacin de un directorio online de web services, 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): Un servicio web es una aplicacin web creada en XML. WSDL (Web Services Definition Service): Este protocolo se encarga de describir el web service cuando es publicado. Es el lenguaje XML que los proveedores emplean para describir sus web services. SOAP (Simple Object Access Protocol): Permite que programas que corren en diferentes sistemas operativos se comuniquen. La comunicacin entre las diferentes entidades se realiza mediante mensajes que son rutados en un sobre SOAP. UDDI (Universal Description Discovery and Integration): Este protocolo permite la publicacin y localizacin de los servicios. Los directorios UDDI actan como una gua telefnica de web services.

Aunque la idea de la programacin modular no es nueva, el xito de esta tecnologa reside en que se basa en estndares conocidos en los que ya se tiene una gran confianza, como el XML. Adems, el uso de los web services aporta ventajas significativas a las empresas. El principal objetivo que se logra, es la interoperabilidad y la integracin. Mediante los web services, las empresas pueden compartir servicios software con sus clientes y sus socios de negocio. Esto ayudar a las compaas a escalar sus negocios, reduciendo el coste en desarrollo y antenimiento de software, y sacando los productos al mercado con mayor rapidez. La integracin de aplicaciones har posible obtener la informacin demandada en tiempo real, acelerando el proceso de toma de decisiones. La evolucin de Internet hacia los web services, mejorar los resultados globales de las empresas, reduciendo sus gastos y guindolas hacia una mejora progresiva de la calidad. La adopcin de la tecnologa de servicios web por la industria es el primer paso hacia una economa global. Posibles riesgos Las expectaciones alrededor de esta tecnologa son grandes, porque el mercado de aplicacin es muy amplio. Pero tambin tiene sus puntos oscuros: Los web services hacen uso de las mismas tecnologas que han sido atacadas en tantas ocasiones. Usando web services, la seguridad de una empresa puede verse comprometida. La ausencia de tcnicas de seguridad estndar es un obstculo para la adopcin de la tecnologa. La calidad de un web service es un parmetro que no queda demasiado claro, pero cuya medida es fundamental a la hora de desarrollar un servicio maduro. Una visin general II Seguridad Actualmente, los web services estn siendo ampliamente aceptados por las empresas para el desarrollo de software de uso interno. De este modo, los servicios pueden implementar toda su funcionalidad y permanecer seguros tras el Cortafuegos de la compaa. Los desarrollos actuales no ayudan a la cooperacin entre las empresas ya que no hay ningn estndar establecido sobre las tcnicas de seguridad. Debido a la tecnologa que es usada por los web services, y en concreto al uso de SOAP, las tcnicas de seguridad convencionales que se han venido usando en Internet, ya no son suficientes. Con SOAP, cada mensaje simple que se intercambia realiza mltiples saltos y es rutado a travs de numerosos puntos antes de que alcance su destino final. Es por ello que los web services necesitan tecnologas que protejan los mensajes desde el principio hasta el final. Existen un conjunto de tcnicas que se pueden usar para garantizar la seguridad a nivel de mensaje. Estas son: Encriptacin 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 y los Certificados: XKMS (XML Key Management Specification) define web services que se pueden usar para chequear la confianza de un certificado de usuario. SAML y la Autorizacin: SAML (Security Assertion Mark-up Language) hace posible que los web services intercambien informacin de autentificacin y autorizacin entre ellos, de modo que un web service confe en un usuario autentificado por otro web service. Validacin de datos: Permite que los web services reciban datos dentro de los rangos esperados.

Adems, tambin hay tcnicas que permiten mantener la seguridad a otros niveles. La seguridad en UDDI permite autentificar todas las entidades que toman parte en la publicacin de un web service: 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. Calidad Actualmente ya existen en el mercado algunas herramientas especficamente diseadas para medir la calidad de los web services, pero sigue siendo necesaria una estandarizacin sobre este tema. Los resultados sobre la calidad de diferentes web services, servirn como parmetro de comparacin y ayudarn al consumidor a decantarse por un servicio u otro. Para que un web service se ejecute con correccin y satisfaga las expectativas creadas, a parte del precio, habr que tener en cuenta una serie de parmetros 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 integracin. Aunque tericamente los web services proporcionan conectividad con cualquier software de un modo transparente, cada proveedor de servicios puede adoptar soluciones diferentes que resultan ms o menos adecuadas para el consumidor.Analizando la escalabilidad se comprobar el grado de modularidad y flexibilidad del servicio. Por ltimo, tambin sera interesante analizar las caractersticas que ofrece el proveedor de web services. Actualmente no hay definidos estndares sobre este tema, pero la mayora de las empresas ya est demandando algn tipo de acuerdo o contrato con los proveedores, de modo que se pueda garantizar la calidad y la fiabilidad de los servicios por los que se paga. Estandarizacin Los web services estn basados en el estndar XML, que ha sido universalmente aceptado. Pero la situacin para el resto de protocolos es bien distinta. La mayor parte de ellos se encuentran todava en desarrollo y pueden ser objeto de cambios. Esa es la razn por la que la mayora de las empresas estn esperando a que estos protocolos sean ms universales antes de profundizar en esta tecnologa. Actualmente, ni SOAP, ni WSDL, ni UDDI han sido oficialmente reconocidos por ningn organismo de estandarizacin. SOAP es el nico que en este momento est en consideracin por el World Wide Web Consortium y se encuentra cercano a la estandarizacin. SOAP y WSDL estn siendo ampliamente usados, pero de momento UDDI no ha tenido el mismo xito. El principal motivo es que las tcnicas de seguridad son todava muy inmaduras y las compaas prefieren hacer uso de registros privados para dar soporte a intercambios

privados de web services. En febrero de este ao, algunas de las empresas ms importantes en el desarrollo de Negocio Electrnico como IBM, Intel, Microsoft o Oracle, han creado el WS-I: organizacin para la Interoperabilidad de los Web Services. El objetivo de dicha organizacin es la promocin de la estandarizacin de los web services de modo que se fomente la cooperacin e interoperabilidad entre las compaas y mercados. Algunos ejemplos Las principales compaas del mundo han empezado a desarrollar soluciones mediante la tecnologa de los web services. Algunos ejemplos son: Microsoft: Recientemente ha anunciado la disponibilidad de su primer web service, llamado MapPoint .Net. Mediante este servicio, el usuario podr conocer su localizacin exacta y otros datos adicionales relacionados con su posicin actual, como informacin de trfico, rutas posibles o puntos comerciales cercanos. IBM: Ha implementado una solucin basada en los web services llamada eBusiness on Demand. Esta solucin permite la construccin de Extranets que ayuden a las empresas a ver los catlogos de productos, realizar y localizar pedidos o chequear el estado del inventario en tiempo real. Lneas Areas Escandinavas: Estas lneas areas han desarrollado un servicio web que permite a los usuarios comprar billetes y chequear el estado de los vuelos, mediante el uso del telfono mvil.

Conceptos e ideas de Web Services "Los web services son componentes software que permiten a los usuarios usar aplicaciones de negocio que comparten datos con otros programas modulares, va Internet. Son aplicaciones independientes de la plataforma que pueden ser fcilmente publicadas, localizadas e invocadas mediante protocolos web estndar, como XML, SOAP, UDDI o WSDL. El objetivo final es la creacin de un directorio de online de web services, que pueda ser localizado de un modo sencillo y que tenga una alta fiabilidad." "Los servicios web son la revolucin informtica de la nueva generacin de aplicaciones que trabajan colaborativamente en las cuales el software esta distribuido en diferentes servidores." "Los servicios XML Web son los bloques de construccin de la computacin distribuida en el Internet. Usted puede crear soluciones al usar los mltiples servicios de XML Web desde varias fuentes que trabajan en conjunto-independientemente de dnde residan o cmo fueron implementadas." XML Web Services Antes de continuar y con el propsito de dejar al lector con una idea lo ms clara posible acerca de el concepto de Web Services (Servicio Web), quiero citar una definicin que rescate al asistir a una charla tcnica de XML Web Service en Microsoft en octubre del 2003 cuyo expositor fue el seor Marcos Escovar. "Un Web Service es un componente de software que se comunica con otras aplicaciones codificando los mensaje en XML y enviando estos mensaje a travs de protocolos estndares de Internet tales como el

Hypertext Transfer Protocol (HTTP). Intuitivamente un Web Service es similar a un sitio web que no cuenta con un interfaz de usuario y que da servicio a las aplicaciones en vez de a las personas. Un Web Service, en vez de obtener solicitudes desde el navegador y retornar paginas web como respuesta, lo que hace es recibir solicitudes a travs de un mensaje formateado en XML desde una aplicacin, realiza una tarea y devuelve un mensaje de respuesta tambin formateado en XML. Microsoft y otras empresas lideres estn promocionando SOAP como estndar de los mensajes para los Web Services. Un mensaje SOAP se parece mucho a una carta : es un sobre que contiene una cabecera con la direccin del receptor del mensaje , un conjunto de opciones de entrega (tal como la informacin de encriptacin), y un cuerpo o body con la informacin o data del mensaje. Microsoft y otros proveedores lderes promocionan los Web Services como un modelo de programacin para la comunicacin entre aplicaciones. Estas compaas piensan que la conexin de aplicaciones a travs de la Internet mejorar la capacidad de las empresas para trabajar conjuntamente con sus socios de negocio, proveedores y clientes. Creando una capa de Web Services sobre una aplicacin corporativa existente, las organizaciones podrn permitir que sistemas externos puedan invocar las funciones de la aplicacin a travs de Internet (o una intranet corporativa) sin tener que modificar la aplicacin misma. Por ejemplo, varias compaas estn hoy en da creando Web Services que actan como front end para aplicaciones de entrada de rdenes que estn residentes internamente en un mainframe. Estas compaas permiten a los sistemas de compras de sus clientes enviar rdenes de compra a travs de la Internet. Poner una capa de web services sobre las aplicaciones existentes es una solucin muy interesante para integrar las aplicaciones desarrolladas por los diferentes departamentos y as reducir los costos de integracin." Ahora que ya tenemos una breve nocin de lo que es un Web Services nos introduciremos en aspectos un poco ms tcnicos. Requisitos de un Web Service Interoperabilidad: Un servicio remoto debe permitir su utilizacin por clientes de otras plataformas. Amigabilidad con Internet: La solucin debe poder funcionar para soportar clientes que accedan a los servicios remotos desde internet. Interfaces fuertemente tipadas: No debera haber ambigedad acerca del tipo de dato enviado y recibido desde un servicio remoto. Ms an, los tipos de datos definidos en el servicio remoto deben poderse corresponder razonablemente bien con los tipos de datos de la mayora de los lenguaje de programacin procedimentales. Posibilidad de aprovechar los estndares de Internet existentes: La implementacin del servicio remoto debera aprovechar estndares de Internet existentes tanto como sea posible y evitar reinventar soluciones a problema que ya se han resuelto. Una solucin construida sobre un estndar de Internet ampliamente adoptado puede aprovechar conjuntos de herramientas y productos existentes creados para dicha tecnologa. Soporte para cualquier lenguaje: La solucin no debera ligarse a un lenguaje de programacin particular Java RMI, por ejemplo, esta ligada completamente a lenguaje Java. Sera muy difcil invocar funcionalidad de un objeto Java remoto desde Visual Basic o PERL. Un cliente debera ser capaz de implementar un

nuevo servicio Web existente independientemente del lenguaje de programacin en el que se halla escrito el cliente Soporte para cualquier infraestructura de componente distribuida: La solucin no debe estar fuertemente ligada a una infraestructura de componentes en particular. De hecho, no se bebera requerir el comprar, instalar o mantener una infraestructura de objetos distribuidos, solo construir un nuevo servicio remoto utilizar un servicio existente. Los protocolos subyacentes deberan proporcionar un nivel base de comunicacin entre infraestructura de objeto distribuidos existentes tales como DCOM y CORBA.

Bloques Constructivos de Servicios Web En el siguiente grafico se muestran los bloques constructivos principales necesarios para facilitar las comunicaciones remotas entre aflicciones. Descubrimiento UDDI,DISCO Descripcin WSDL, Esquema XML, Docs Formato de Mensaje SOAP Codificacin XML Transporte HTTP,SMTP y otros Figura II.1: "Bloques constructivos de Servicios Web" Descubrimiento: La aplicacin cliente que necesita acceder a la funcionalidad que expone un Servicio Web necesita una forma de resolver la ubicacin de servicio remoto. Se logra mediante un proceso llamado, normalmente descubrimiento (discovery). El descubrimiento se puede proporcionar mediante un directorio centralizado as como por otros mtodos ad hoc. En DCOM, el servicio de descubrimiento lo proporciona el Administrador de control de servicios (SCM, Services Control Manager). Descripcin: Una vez que se ha resuelto el extremo de un servicio Web dado, el cliente necesita suficiente informacin para interactuar adecuadamente con el mismo. La descripcin de un servicio Web implica meta datos estructurados sobre la interfaz que intenta utilizar la aplicacin cliente as como documentacin escrita sobr el servicio Web incluyendo ejemplo de uso. Un componente DCOM expone meta datos estructurados sobre sus interfaces mediante una iblioteca de tipo (typelib). Los meta datos dentro de una typelib de componente se guardan en un formato binario propietario a los que se accede mediante una interfaz de programacin de aplicacin (API) propietaria. Formato del mensaje: Para el intercambio de datos, el cliente y el servidor tienen que estar de acuerdo en un mecanismo comn de codificacin y formato de mensaje. El uso de un mecanismo estndar de codificar los datos asegura que los datos que codifica el cliente los interpretar correctamente el servidor. En DCOM los mensajes que se envan entre un cliente y un servidor tienen un formato definido por el protocolo DCOM Object RPC (ORPC).

Codificacin: Los datos que se trasmiten entre el cliente y el servidor necesitan codificarse en un cuerpo de mensaje. Dcom utiliza un esquema de codificacin binaria para serializar los datos de los parmetros que se intercambian entre el cliente y el servidor. Transporte: Una vez se ha dado formato al mensaje y se han serializado los datos en el cuerpo del mensaje se debe transferir entre el cliente y el servidor utilizando algnprotocolo de transporte. DCOM dispone de varios protocolos propietarios como TCP, SPX,NetBEUI y NetBIOS sobre IPX.

SOAP (Simple Object Access Protocol) Qu es SOAP? Son las siglas de Simple Object Access Protocol. Este protocolo deriva de un protocolo creado por David Winer, XML-RPC en 1998. En su sitio web, Userland, http://www.userland.com/ se puede encontrar multitud de documentacin acerca de este primer protocolo de comunicacin bajo http mediante XML. Con este protocolo se pedan realizar RPC o remote procedure calls, es decir, podamos bien en cliente o servidor realizar peticiones mediante http a un servidor web. Los mensajes deban tener un formato determinado empleando XML para encapsular los parmetros de la peticin. Con el paso del tiempo el proyecto iniciado por David Winer interes a Importantes multinacionales entre las que se encuentran IBM y Microsoft y de este inters por XML-RPC se desarrollo SOAP." En el ncleo de los servicios Web se encuentra el protocolo simple de acceso a datos SOAP, que proporciona un mecanismo estndar de empaquetar mensajes. SOAP ha recibido gran atencin debido a que facilita una comunicacin del estilo RPC entre un cliente y un servidor remoto. Pero existen multitud de protocolos creados para facilitar la comunicacin entre aplicaciones, incluyendo RPC de Sum, DCE de Microsoft, RMI de Java y ORPC de CORBA. Por qu se presta tanta atencin a SOAP? Una de las razones principales es que SOAP ha recibido un increble apoyo por parte de la industria. SOAP es el primer protocolo de su tipo que ha sido aceptado prcticamente por todas las grandes compaas de software del mundo. Compaas que en raras ocasiones cooperan entre s estn ofreciendo su apoyo a este protocolo. Algunas de las mayores Compaas que soportan SOAP son Microsoft, IBM, SUN, Microsystems, SAP y Ariba. Algunas de las Ventajas de SOAP son: No esta asociado con ningn lenguaje: los desarrolladores involucrados en nuevos proyectos pueden elegir desarrollar con el ultimo y mejor lenguaje de programacin que exista pero los desarrolladores responsables de mantener antiguas aflicciones heredadas podran no poder hacer esta eleccin sobre el lenguaje de programacin que utilizan. SOAP no especifica una API, por lo que la implementacin de la API se deja al lenguaje de programacin, como en Java, y la plataforma como Microsoft .Net.

No se encuentra fuertemente asociado a ningn protocolo de transporte: La especificacin de SOAP no describe como se deberan asociar los mensajes de SOAP con HTTP. Un mensaje de SOAP no es ms que un documento XML, por lo que puede transportarse utilizando cualquier protocolo capaz de transmitir texto. No est atado a ninguna infraestructura de objeto distribuido La mayora de los sistemas de objetos distribuidos se pueden extender, y ya lo estn alguno de ellos para que admitan SOAP. Aprovecha los estndares existentes en la industria: Los principales contribuyentes a la especificacin SOAP evitaron, intencionadamente, reinventar las cosas. Optaron por extender los estndares existentes para que coincidieran con sus necesidades. Por ejemplo, SOAP aprovecha XML para la codificacin de los mensajes, en lugar de utilizar su propio sistema de tipo que ya estn definidas en la especificacin esquema de XML. Y como ya se ha mencionado SOAP no define un medio de trasporte de los mensajes; los mensajes de SOAP se pueden asociar a los protocolos de transporte existentes como HTTP y SMTP. Permite la interoperabilidad entre mltiples entornos: SOAP se desarrollo sobre los estndares existentes de la industria, por lo que las aplicaciones que se ejecuten en plataformas con dicho estndares pueden comunicarse mediante mensaje SOAP con aplicaciones que se ejecuten en otras plataformas. Por ejemplo, una aplicacin de escritorio que se ejecute en una PC puede comunicarse con una aplicacin del back-end ejecutndose en un mainframe capaz de enviar y recibir XML sobre HTTP.

Anatoma de un mensaje de SOAP SOAP proporciona un mecanismo estndar de empaquetar un mensaje. Un mensaje SOAP se compone de un sobre que contiene el cuerpo del mensaje y cualquier informacin de cabecera que se utiliza para describir le mensaje. A continuacin tiene un ejemplo:

Figura III.1: "Anatoma de un mensaje SOAP"

El elemento raz del documento es el elemento Envelope. El ejemplo contiene dos subelementos, Body y Header. Un ejemplo de SOAP valido tambin puede contener otros elementos hijo en el sobre. El sobre puede contener un elemento Header opcional que contiene informacin sobre el mensaje. En el ejemplo anterior, la cabecera contiene dos elementos que describen a quien compuso el mensaje, y posible receptor del mismo. El sobre debe contener un elemento body el elemento body (cuerpo) contiene la carga de datos del mensaje. En el ejemplo el cuerpo contiene una simple cadena de caracteres. Un mensaje debe estar dentro de sobre de SOAP bien construido. Un sobre se compone de un nico elemento envelope el sobre puede contener un elemento Header y puede contener un elemento body. Si existe, la cabecera debe ser el elemento hijo inmediato del sobre, con el cuerpo siguiendo inmediatamente a la cabecera. El cuerpo contiene la carga de datos del mensaje y la cabecera contiene los datos adicionales que no pertenecen necesariamente al cuerpo del mensaje. Adems de definir un sobre de SOAP, la especificacin de SOAP define una forma de codificar los datos contenidos en un mensaje. La codificacin de SOAP proporciona un mecanismo estndar para zerialisar tipos de datos no definidos en la parte 1 de la especificacin del esquema de XML. La especificacin de SOAP tambin proporciona un patrn de mensaje estndar para facilitar el comportamiento de tipo RPC. Se emparejan dos mensajes de SOAP para facilitar la asociacin de un mensaje de peticin con un mensaje de respuesta. La llamada a un mtodo y sus parmetros se serializan en el cuerpo del mensaje de peticin en forma de una estructura. El elemento raz tiene el mismo nombre que el mtodo objetivo, con cada uno de los parmetros codificado como un subelemento. El mensaje de respuesta puede contener los resultados de la llamada al mtodo o una estructura de fallo bien definida. Los resultados de la llamada a un mtodo se serializan en el cuerpo de la peticin como una estructura. Por convenio, el elemento raz tiene el mismo nombre que el mtodo original al que se aade result. Los parmetros de retorno se serializan como elementos hijo, con el parmetro de retorno en primer lugar. Si se encuentra un error el cuerpo del mensaje de respuesta contendr una estructura de fallo bien definida. Por convenio, el elemento raz tiene el mismo nombre que el mtodo original al que se aade result. Los parmetros de retorno se serializan como elementos hijo, con el parmetro de retorno en primer lugar. Si se encuentra un error el cuerpo del mensaje de respuesta contendr una estructura de fallo bien definida. XML: el lenguaje de los Servicios Web En este apartado conocemos por as decirlo el lenguaje sobre el cual se soportan los servicios Web, su nombre es XML. No es intencin explicar detalladamente la sintaxis de este lenguaje si no ms bien no evocaremos a aspectos ms generales como sus orgenes, sus caractersticas principales y porque es el lenguaje escogido para desarrolla servicios Web.

Vista general de XML El cdigo html permite insertar mens, tablas, imgenes o bases de datos en los documentos, pero no permite al usuario que maneje esos elementos como mejor le convenga con la poderosa ayuda del ordenador. Esa es la principal novedad que XML aporta. Con HTML se pueden hacer accesos a informacin comparativa en diferentes tiendas por ejemplo, pero nada ms. Con XML el usuario podr ordenar los datos o actualizarlos en tiempo real o realizar un pedido. La informacin que manejan las empresas es uno de sus principales activos. Pero lo normal es que esa informacin est fragmentada, en diferentes departamentos, ordenadores conectados o no, etc. El reto ahora est en interrelacionar toda esa informacin para rendir todo su potencial y ponerlo a trabajar para aumentar los beneficios o reducir los costes. Para realizar esto se necesita un estndar de almacenamiento estructurado que es lo que nos ofrece XML. Una gran cantidad de gente ha odo hablar ltimamente de XML y mucha gente que es una especie de HTML pero ms avanzado. Pero todo el mundo lo que debera preguntarse es qu es exactamente XML y qu aplicaciones tiene actualmente. De estas dos cuestiones el mayor error que se suele cometer es considerar a XML un HTML extendido. Lo que s tenemos ms o menos claro es que XML es un lenguaje de Marcas, pero qu es exactamente un lenguaje de marcas. Lenguajes de Marcas En los aos 60, IBM intent resolver sus problemas asociados al tratamiento de documentos en diferentes plataformas a travs de GML (Generalized markup Language. El principal problema era que cada aplicacin utilizaba sus propias marcas para describir los diferentes elementos. Las marcas son cdigos que indican a un programa cmo debe tratar su contenido y as, si se desea que un texto aparezca con un formato determinado, dicho texto debe ir delimitado por la correspondiente marca que indique como debe ser mostrado en pantalla o impreso. Y lo mismo ocurre con todas las dems caractersticas de cualquier texto. Ejemplos pueden tenerlos en mente los usuarios de WordPerfect. Conociendo este sistema y conociendo a la perfeccin el sistema de marcas de cada aplicacin sera posible pasar informacin de un sistema a otro sin necesidad de perder el formato indicado. La forma que IBM cre para solventar esto se basaba en tratar las marcas como texto accesible desde cualquier sistema, texto plano, cdigo ASCII. Y la norma se denomin GML (General Modeling Language. Ms tarde GML pas a manos de ISO y se convirti en SGML ( ISO 8879), Standart Generalized Markup Language. Esta norma es la que se aplica desde entonces a todos los lenguajes de marcas, cuyos ejemplos ms conocidos son el HTML y el RTF. Los lenguajes de marcas no son equivalentes a los lenguajes de programacin aunque se definan igualmente como "lenguajes". Son sistemas complejos de descripcin de informacin, normalmente documentos, que si se ajustan a SGML, se pueden controlar desde cualquier editor ASCII. Las marcas ms utilizadas suelen describirse por textos

descriptivos encerrados entre signos de "menor" (<) y "mayor" (>), siendo lo ms usual que existan una marca de principio y otra de final. Se puede decir que existen tres utilizaciones bsicas de los lenguajes de marcas: los que sirven principalmente para describir su contenido, los que sirven ms que nada para definir su formato y los que realizan las dos funciones indistintamente. Las aplicaciones de bases de datos son buenas referencias del primer sistema, los programas de tratamiento de textos son ejemplos tpicos del segundo tipo, y aunque no lo parezca, el HTML es la muestra ms conocida del tercer modelo. Qu es XML? XML, es el estndar de Extensible Markup Language. XML no es ms que un conjunto de reglas para definir etiquetas semnticas que nos organizan un documento en diferentes partes. XML es un metalenguaje que define la sintaxis utilizada para definir otros lenguajes de etiquetas estructurados. En primer lugar para entenderlo bien hay que olvidarse un poco, slo un poco de HTML. En teora HTML es un subconjunto de XML especializado en presentacin de documentos para la Web, mientras que XML es un subconjunto de SGML especializado en la gestin de informacin para la Web. En la prctica XML contiene a HTML aunque no en su totalidad. La definicin de HTML contenido totalmente dentro de XML y por lo tanto que cumple a rajatabla la especificacin SGML es XHTML (Extensible, Hypertext Markup Language). Desde su creacin, XML ha despertado encontradas pasiones, y como para cualquier tema en Internet, hay gente que desde el principio se deja iluminar por sus expectativas, mientras otras muchas lo han ignorado. Historia de XML XML fue creado al amparo del Word Wide Web Consortium (W3C) organismo que vela por el desarrollo de WWW partiendo de las amplias especificaciones de SGML. Su desarrollo se comenz en 1996 y la primera versin sali a la luz el 10 de febrero de 1998. La primera definicin que apareci fue: Sistema para definir validar y compartir formatos de documentos en la web. Durante el ao 1998 XML tuvo un crecimiento exponencial, y con ello me refiero a sus apariciones en medios de comunicacin, menciones en pginas web, soporte software, etc. Respecto a sus objetivos son: XML debe ser directamente utilizable sobre Internet. XML debe soportar una amplia variedad de aplicaciones. XML debe ser compatible con SGML. Debe ser fcil la escritura de programas que procesen documentos XML. El nmero de caractersticas opcionales en XML debe ser absolutamente mnimo, idealmente cero. Los documentos XML deben ser legibles por humanos y razonablemente claros.

El diseo de XML debe ser preparado rpidamente. El diseo de XML debe ser formal y conciso. Los documentos XML deben ser fcilmente creables. La concisin en las marcas XML es de mnima importancia. Esta especificacin, junto con los estndares asociados (Unicode e ISO/IEC 10646 para caracteres, Internet RFC 1766 para identificacin de lenguajes, ISO 639 para cdigos de nombres de lenguajes, e ISO 3166 para cdigos de nombres de pases), proporciona toda la informacin necesaria para entender la Versin 1.0 de XML y construir programas de computador que los procesen.

Principales caractersticas Es una arquitectura ms abierta y extensible. No se necesita versiones para que puedan funcionar en futuros navegadores. Los identificadores pueden crearse de manera simple y ser adaptados en el acto en internet/intranet por medio de un validador de documentos (parser). Mayor consistencia, homogeneidad y amplitud de los identificadores descriptivos del documento con XML (los RDF Resource Description FrameWork), en comparacin a los atributos de la etiqueta del HTML. Integracin de los datos de las fuentes ms dispares. Se podr hacer el intercambio de documentos entre las aplicaciones tanto en el propio PC como en una red local o extensa. Datos compuestos de mltiples aplicaciones. La extensibilidad y flexibilidad de este lenguaje nos permitir agrupar una variedad amplia de aplicaciones, desde pginas web hasta bases de datos. Gestin y manipulacin de los datos desde el propio cliente web. Los motores de bsqueda devolvern respuestas ms adecuadas y precisas, ya que la codificacin del contenido web en XML consigue que la estructura de la informacin resulte ms accesible. Se desarrollarn de manera extensible las bsquedas personalizables y subjetivas para robots y agentes inteligentes. Tambin conllevar que los clientes web puedan ser ms autnomos para desarrollar tareas que actualmente se ejecutan en el servidor. Se permitir un comportamiento ms estable y actualizable de las aplicaciones web, incluyendo enlaces bidireccionales y almacenados de forma externa (El famoso epgrafe "404 file not found" desaparecer). El concepto de "hipertexto" se desarrollar ampliamente (permitir denominacin independiente de la ubicacin, enlaces bidireccionales, enlaces que pueden especificarse y gestionarse desde fuera del documento, hiperenlaces mltiples, enlaces agrupados, atributos para los enlaces, etc. Creado a travs del Lenguaje de enlaces extensible (XLL). Exportabilidad a otros formatos de publicacin (papel, web, cd-rom, etc.). El documento maestro de la edicin electrnica podra ser un documento XML que se integrara en el formato deseado de manera directa.

Estructura del XML El metalenguaje XML consta de cuatro especificaciones (el propio XML sienta las bases sintcticas y el alcance de su implementacin):

DTD (Document Type Definition) Definicin del tipo de documento. Es, en general, un archivo/s que encierra una definicin formal de un tipo de documento y , a la vez, especifica la estructura lgica de cada documento. Define tanto los elementos de una pgina como sus atributos. El DTD del XML es opcional. En tareas sencillas no es necesario construir una DTD, entonces se tratara de un documento "bien formado"(wellformed) y si lleva DTD ser un documento "validado" (valid). XSL (eXtensible Stylesheet Language) Define o implementa el lenguaje de estilo de los documentos escritos para XML. Desde el verano de 1997 varias empresas informticas como Arbortext, Microsoft e Inso vienen trabajando en una propuesta de XSL (antes llamado "xml-style") que presentaron a W3C. Permite modificar el aspecto de un documento. Se puede lograr mltiple columnas, texto girado, orden de visualizacin de los datos de una tabla, mltiples tipos de letra con amplia variedad en los tamaos. Este estndar est basado en el lenguaje de semntica y especificacin de estilo de documento (DSSSL, Document Style Semantics and Specification Language, ISO/IEC 10179) y, por otro lado, se considera ms potente que las hojas de estilo en cascada (CSS, Cascading Style Sheets), usado en un principio con el lenguaje DHTML. "Se espera que el CSS sea usado para visualizar simples estructuras de documentos XML (actualmente se ha conseguido mayor integracin en XML con el protocolo CSS2 (Cascading Style Sheets, level 2) ofreciendo nuevas formas de composicin y una ms rpida visualizacin) y, por otra parte, XSL pueda ser utilizado donde se requiera ms potencia de diseo como documentos XML que encierran datos estructurados (tablas, organigramas, etc.)(2)". XLL (eXtensible Linking Language) Define el modo de enlace entre diferentes enlaces. Se considera que es un subconjunto de HyTime (Hipermedia/Timed-based structuring Language o Lenguaje de estructuracin hipermedia/basado en el tiempo, ISO 10744) y sigue algunas especificaciones del TEI (Text Encoding Initiative o Iniciativa de codificacin de texto). Desde marzo de 1998 el W3C trabajo en los enlaces y direccionamientos del XML. Provisionalmente se le renombr como Xlink y a partir de junio se le denomina XLL. Este lenguaje de enlaces extensible tiene dos importantes componentes: Xlink y el Xpointer. Va ms all de los enlaces simples que slo soporta el HTML. Se podr implementar con enlaces extendidos. Jon Bosak establece los siguientes mecanismos hipertextuales que soportar esta especificacin: Denominacin independiente de la ubicacin. Enlaces que pueden ser tambin bidirecccionales. Enlaces que pueden especificarse y gestionarse desde fuera del documento a los que se apliquen (Esto permitir crear en un entorno intranet/extranet un banco de datos de enlaces en los que se puede gestionar y actualizar automticamente. No habr ms errores del tipo "404 Not Found"). Hiperenlaces mltiples (anillos, mltiples ventanas, etc.). Enlaces agrupados (mltiples orgenes). Transclusin (el documento destino al que apunta el enlace aparece como parte integrante del documento orgen del enlace). Se pueden aplicar atributos a los enlaces (tipos de enlaces). XUA (XML User Agent): Estandarizacin de navegadores XML. Todava est en proceso de creacin de borradores de trabajo. Se aplicar a los navegadores para que compartan todas las especificaciones XML.

XML y Los Servicios Web Finalmente ahora que ya conocemos algo ms sobre XML no queda responde porque XML es utilizado en los servicios Web? Si recapitulamos todo los captulos anteriores seguro ya tendremos alguna pista para esta pregunta, pero para hacerlo ms prctico diremos que se utiliza XML porque: Es un estndar abierto es decir que es reconocido mundialmente ya que muchas compaas tecnolgicas integran en sus software compatibilidad con dicho lenguaje. Esto quiere decir que la gran mayora de software de escritorio de sistema operativo, aplicaciones mviles permiten la compatibilidad con XML esto lo hace muy potente a la hora de permite la comunicacin entre distintas plataformas de software y hardware (y si bien recordamos este es el sentido final de los Servicios Web). Simplicidad de sintaxis esto quiere decir que es muy fcil de escribir cdigo en XML y la representacin de los datos es casi entendible por cualquier ser humano. Esto lo hace muy flexible a la hora de querer reprensar datos de cualquier especie, bastara con contar con cualquier editor de texto y aprende unas cuantas intrusiones bsicas y ya esta en condiciones de escribir cdigo XML el cual ser soportado o entendido por cualquier aplicacin que pueda leer documentos XML. El hecho de que XML sea tan fcil de codificar y de entender lo hace el lenguaje ideal para utilizarlo en los servicios Web. Independencia del protocolo de Transporte, el hecho de que XML es un lenguaje de Marcado de Texto, no necesita de ningn protocolo de trasporte especial, solo necesita de un protocolo que pueda trasferir texto o documentos simples. Esto nos trae a la memoria que en mercado existen muchos protocolos con estas caracterstica como lo son los mas conocidos en HTTP y SMTP por nombrar algunos. Volviendo la tema de los servicios Web una de las caracterstica de estos es la independencia del protocolo de trasporte.

WSDL para la documentacin de Servicios Web El esquema XML por s solo no puede describir totalmente un Servicio Web. Supongamos que se ha creado un servicio Web Calculadora. Este servicio Web expone los mtodos sumar y restar. Ambos mtodos aceptan dos enteros y devuelven un nico entero con el resultado; sumar devuelve la suma de los dos enteros y restar devuelve su diferencia. En un esfuerzo para describir cmo interacciona un cliente con el servicio Web se define un esquema para los mensajes que se intercambiarn entre el cliente y el servidor. El esquema contiene una definicin de un tipo de complejo para los mensaje de peticin y repuesta para los mtodos sumar y restar. Recuerde que el objetivo ltimo es que los desarrolladores no tengan que investigar en las definiciones del esquema intentando descifrar cmo interaccionar con el servicio Web. En lugar de ello se quiere describir el servicio de forma que una herramienta pueda descifrarlo y crear un proxy por el cliente. Adems de la informacin que proporciona el esquema, Qu ms necesita conocer el cliente para invocar los mtodos que expone el Servicio Web Calculadora? Como el cuerpo de un mensaje de SOAP puede contener cualquier cosa que no invalide el XML los mensajes de SOAP se pueden combinar para disponer de una amplia variedad de

patrones de intercambio de mensajes. Los patrones de intercambio de mensajes para el Servicio Web Calculadora son bastante inmediatos pero una asociacin formal entre los mensajes de peticin Sumar y Restar y sus mensajes de respuesta asociados eliminaran cualquier posible ambigedad. Una descripcin formal de los patrones de mensaje resulta an ms importante en el caso de Servicio Web ms complejos. Algunos servicios podran aceptar una peticin pero no enviar la respuesta correspondiente devuelta al cliente. Otros podran solamente enviar mensajes al cliente. Adems, el esquema no contiene informacin sobre cmo acceder al Servicio Web. Como SOAP es independiente del protocolo, se intercambiarn los mensajes entre el cliente y el servidor de numerosas formas. Cmo se sabe si hay que enviar un mensaje mediante HTTP, SMTP o cualquier otro protocolo de transporte? Ms an, cmo se sabe la direccin la que hay que enviar el mensaje? El lenguaje de descripcin de servicios Web (WSDL, Web Service Description Language) es un dialecto basado en XML sobre el esquema que describe un servicio Web. Un documento WSDL proporciona la informacin necesaria al cliente para interaccionar con el servicio Web. WSDL es extensible y se pude utilizar para describir, prcticamente, cualquier servicio de red, incluyendo SOAP sobre HTTP e incluso protocolos que no se basan en XML como DCOM sobre UDP. Dado que los protocolos de comunicaciones y los formatos de mensajes estn estandarizados en la comunidad del Web, cada da aumenta la posibilidad e importancia de describir las comunicaciones de forma estructurada. WSDL afronta esta necesidad definiendo una gramtica XML que describe los servicios de red como colecciones de puntos finales de comunicacin capaces de intercambiar mensajes. Las definiciones de servicio de WSDL proporcionan documentacin para sistemas distribuidos y sirven como frmula para automatizar los detalles que toman parte en la comunicacin entre aplicaciones. Los documentos WSDL definen los servicios como colecciones de puntos finales de red o puertos. En WSDL, la definicin abstracta de puntos finales y de mensajes se separa de la instalacin concreta de red o de los enlaces del formato de datos. Esto permite la reutilizacin de definiciones abstractas: mensajes, que son descripciones abstractas de los datos que se estn intercambiando y tipos de puertos, que son colecciones abstractas de operaciones. Las especificaciones concretas del protocolo y del formato de datos para un tipo de puerto determinado constituyen un enlace reutilizable. Un puerto se define por la asociacin de una direccin de red y un enlace reutilizable; una coleccin de puertos define un servicio. Por esta razn, un documento WSDL utiliza los siguientes elementos en la definicin de servicios de red: Types: contenedor de definiciones del tipo de datos que utiliza algn sistema de tipos (por ejemplo XSD). Message: definicin abstracta y escrita de los datos que se estn comunicando. Operation: descripcin abstracta de una accin admitida por el servicio. Port Type: conjunto abstracto de operaciones admitidas por uno o ms puntos finales. Binding: especificacin del protocolo y del formato de datos para un tipo de puerto determinado.

Port: punto final nico que se define como la combinacin de un enlace y una direccin de red. Service: coleccin de puntos finales relacionados.

A continuacin se detalla un poco ms en profundidad cada uno de estos elementos Elemento types El elemento Types contiene informacin de esquema referenciado en el documento WSDL. El sistema de tipos predeterminado que admite WSDL es de esquema de XML. Si se usa esquema de XML para definir los tipos que contiene el elemento Types el elemento schema aparecer inmediatamente como elemento hijo. Se puden utilizar otros sistemas de tipo tipos por extensin. Si desea, utilizar otro sistema de tipo pude aparecer un elemento de extensibilidad bajo el elemento Types. El nombre de este elemento debera identificar el sistema de tipos utilizados. En este captulo se limitar a tratar el esquema de XML porque es el sistema de tipos dominante en los documento WSDL. Elemento message El elemento Message proporciona una abstraccin comn para el paso de mensajes entre el cliente y el servidor. Como puede utilizar mltiples formatos de de definicin de esquema en documento WSDL es necesario de disponer de un mecanismo comn de identificar los mensajes. El elemento Message proporciona este nivel comn de abstraccin al que se har referencia en otras partes del documento WSDL. Pude Aparecer, y normalmente aparecern, mltiples elementos Message en un documento WSDL, uno para cada mensaje que se comunica entre el cliente y el servidor. Cada mensaje contiene uno o ms elementos "Part" que describen las piezas del contenido del mensaje. Un ejemplo de una parte es el cuerpo de un mensaje de SOAP o un parmetro que forma parte de una cadena de peticin, un parmetro codificado en el cuerpo del mensaje de SOAP o todo el cuerpo de un mensaje de SOAP. Elemento portType El elemento porType contiene un conjunto de operaciones abstractas que representan los tipos de correspondencia que pueden producirse entre el cliente y el servidor. Para los Servicios Web de estilo RPC se pude pensar en un porType como una definicin de internas en donde cada mtodo se pude definir como una operacin. Un tipo puerto se compone de un conjunto de electos operation que define una determinada accin. Los electos operation se componen de mensajes definidos en el documento WSDL. WSDL define cuatro tipos de operaciones denominadas tipo operaciones: Request-response(peticin-respuesta) comunicacin del tipo RPC en la que le cliente realiza una peticin y el servidor enva la correspondiente respuesta. One-way (un-sentido) Comunicacin del estilo documento en la que el cliente enva ubn mensaje pero no recibe una respuesta del servidor indicando el resultado del mensaje procesado. Solicit-response(solicitud-respuesta) La contraria a la operacin peticinrespuesta. El servidor enva una peticin y el cliente le enva de vuelta una respuesta.

Notification (Notificacin) La contraria a la operacin un-sentido el servidor enva una comunicacin del estilo documento al cliente.

Elemento binding El elemento binding contiene las definiciones de la asociacin de un protocolo como SOAP a un determinado bindingType. Las definiciones binding especifican detalles de formatos del mensaje y el protocolo. Por ejemplo, la informacin de asociacin especifica si se puede acceder a una instancia de un portType de forma RPC. Las definiciones binding tambin indican el nmero de comunicaciones de re red que se requieren para realizar una determinada accin. Por ejemplo, una llamada RPC de SOAP sobre HTTP podra involucrar un intercambio de comunicacin HTTP, pero esa misma llamada sobre SMTP podra involucrar dos intercambios de comunicaciones de SMTP discretas. La asociacin de logra utilizando elementos de extensin. Cada protocolo tiene su propio conjunto de elementos de extensin para especificar los detalles del protocolo y el formato de los mensajes. Para un determinado protocolo los elementos de extensin se suelen utilizar para decorar las acciones individuales de una operacin y la propia operacin con la informacin de asociacin del protocolo. A veces los elementos de extensin se utilizan en el propio nivel portType. Elemento service Un servicio es un grupo de puertos relacionados y se definen en el elemento service. Un puerto es un extremo concreto de un Servicio Web al que se hace referencia por una direccin nica. Los puertos que se definen en determinado servicio son independientes. Por ejemplo, la salida de un puerto que no puede utilizarse como una entrada de otro. Elementos de Extensibilidad Los elementos de extensibilidad se utilizan para representar determinadas tecnologas. Por ejemplo, se puede utilizar los elementos de extensibilidad para especificar el idioma en que se utiliza en el esquema de los elementos types. El esquema para un determinado conjunto de elementos de extensibilidad se debe definir dentro de distintos espacios de nombres que WSDL. La definicin de los propios elementos puede contener un atributo wsdl:requiered que indique un valor boolean si el atributo requiered se establece a true en una definicin de elementos una asociacin que haga referencia a ese conjunto concreto de electos de extensibilidad tiene que incluir dicho elemento. Lo ms habitual es que los elementos de extensibilidad se utilicen para especificar especificacin de asociacin. La especificacin WSDL define conjunto de elementos de extensibilidad para la asociacin SOAP, HTTP GET, HTTP POS, MIME. Sin embargo, la especificacin slo define las asociaciones para dos de los cuatro tipos de operaciones. Un sentido y peticin repuesta.

UDDI (Universal Description Discovery and Integration) Hasta ahora, se ha explicado cmo crear un servicio Web en una situacin real, describiendo desde los documentos de diseo iniciales hasta las repercusiones empresariales o la implementacin final. Lgicamente, el siguiente paso consiste en definir cmo se dar a conocer el servicio Web para que los clientes interesados puedan descubrirlo fcilmente y utilizarlo en sus aplicaciones. En la actualidad, ya existe un mecanismo de descubrimiento que cumple estos requisitos: UDDI (Universal Description Discovery and Integration), una iniciativa del sector para hacer compatible el descubrimiento de servicios Web con todo tipo de tecnologas y plataformas. En primer lugar, analizar las repercusiones de UDDI, desde un punto de vista tanto tecnolgicocomo empresarial. A continuacin, explicar la relacin entre UDDI y WDSL (Lenguaje de descripcin de servicios Web. Por ltimo, describir el proceso de registro en UDDI y los puntos que se deben tener en cuenta para maximizar su potencial. UDDI Un registro global de servicios Web UDDI es un registro pblico diseado para almacenar de forma estructurada informacin sobre empresas y los servicios que stas ofrecen. A travs de UDDI, se puede publicar y descubrir informacin de una empresa y de sus servicios. Se puede utilizar sistemas taxonmicos estndar para clasificar estos datos y poder encontrarlos posteriormente en funcin de la categorizacin. Lo ms importante es que UDDI contiene informacin sobre las interfaces tcnicas de los servicios de una empresa. A travs de un conjunto de llamadas a API XML basadas en SOAP, se puede interactuar con UDDI tanto en tiempo de diseo como de ejecucin para descubrir datos tcnicos de los servicios que permitan invocarlos y utilizarlos. De este modo, UDDI sirve como infraestructura para una coleccin de software basado en servicios web Por qu UDDI? Por qu resulta necesario un registro de este tipo? Teniendo en cuenta que existe una coleccin de software de miles (quizs millones) de servicios Web, se nos plantean varias cuestiones difciles: Cmo se descubren los servicios Web? Cmo se categoriza la informacin de forma coherente? Cmo repercute esto en la localizacin? Cmo afecta a las tecnologas de propietario? Cmo se puede garantizar la interoperabilidad del mecanismo de descubrimiento? Cmo se puede interactuar en tiempo de ejecucin con este mecanismo de descubrimiento cuando mi aplicacin depende de un servicio Web? La iniciativa UDDI surgi como respuesta a estas preguntas. Varias empresas, incluidas Microsoft, IBM, Sun, Oracle, Compaq, Hewlett Packard, Intel, SAP y unas trescientas ms (para obtener un listado completo, consulte UDDI: Community [en ingls]), unieron sus esfuerzos para desarrollar una especificacin basada en estndares abiertos y tecnologas no propietarias que permitiera resolver los retos anteriores. El resultado, cuya versin beta se lanz en diciembre de 2000 y estaba en produccin en mayo de 2001, fue un registro empresarial global alojado por varios nodos de operadores en el que los usuarios podan realizar bsquedas y publicaciones sin coste alguno. A partir de la creacin de esta infraestructura para servicios Web, los datos sobre estos servicios se pueden encontrar de forma sistemtica y confiable en una capacidad

universal totalmente independiente de proveedores. Se pueden llevar a cabo bsquedas categricas precisas utilizando sistemas de identificacin y taxonmicos extensibles. La integracin de UDDI en tiempo de ejecucin se puede incorporar a las aplicaciones. Como resultado, se fomenta el desarrollo de un entorno de software de servicios Web. Cmo funciona UDDI? La informacin de UDDI se aloja en nodos de operador, empresas que se han comprometido a ejecutar un nodo pblico conforme a la especificacin que rige el consorcio UDDI.org. En la actualidad existen dos nodos pblicos que se ajustan a la versin 1 de la especificacin UDDI: Microsoft aloja uno e IBM el otro. Hewlett Packard se ha comprometido a alojar un nodo bajo la versin 2 de la especificacin. Los operadores del host deben replicar datos entre ellos a travs de un canal seguro, para conseguir la redundancia de la informacin en el registro UDDI. Se pueden publicar los datos en un nodo y descubrirlos en otro tras la rplica. Actualmente, la rplica se produce cada 24 horas. En el futuro, este intervalo entre rplicas se reducir, ya que habr ms aplicaciones que dependan de los datos de UDDI. Resulta importante observar que no existen requisitos de propietario respecto al modo en que el operador del host implementa su nodo. El nodo slo se debe ajustar a la especificacin UDDI. El nodo de Microsoft (http://uddi.microsoft.com/default.aspx [en ingls]), por ejemplo, se ha escrito por completo en C# y se ejecuta en produccin en tiempo de ejecucin en lenguaje comn .NET Beta 2. El cdigo de base se beneficia claramente de la compatibilidad nativa con SOAP y de la serializacin que ofrecen las clases de sistema .NET. En el lado del servidor, el nodo del operador Microsoft utiliza Microsoft SQL Server 2000 como almacn de datos. Creo que basta con mencionar que IBM utiliza tecnologas diferentes para ejecutar su nodo, verdad?. No obstante, los dos nodos se comportan exactamente igual, ya que se ajustan al mismo conjunto de llamadas a API XML basadas en SOAP. Las herramientas de los clientes pueden interoperar con ambos nodos sin problemas. Por eso, el nodo pblico UDDI constituye un claro ejemplo de que el modelo de servicios Web XML funciona en entornos heterogneos. El prximo paso para comprender la iniciativa UDDI consiste en ver qu datos se almacenan en UDDI y cmo se estructuran. UDDI es relativamente ligero; se ha diseado como registro, no como depsito. La diferencia, aunque sutil, resulta esencial. Un registro redirige al usuario a recursos, mientras que un depsito slo almacena informacin. El registro Microsoft Windows puede servir de ejemplo: contiene las configuraciones y parmetros bsicos pero, en ltima instancia, su funcin es la de dirigir la aplicacin a un recurso o binario. Buscar un componente COM basndonos en su Id. de programa nos conducir a un Id. de clase, que a su vez nos dirigir a la ubicacin del binario. UDDI se comporta de forma similar: como el registro de Windows, se basa en identificadores nicos globales (GUID) para garantizar la capacidad de bsquedas y determinar la ubicacin de recursos. En ltima instancia, las consultas a UDDI conducen a una interfaz (un archivo .WSDL, .XSD, .DTD, etc.) o a una implementacin (como un archivo .ASMX o .ASP) ubicadas en otro servidor. Por tanto, UDDI puede responder a este tipo de preguntas: "Qu interfaces de servicios Web basadas en WSDL se han publicado y establecido para un sector determinado?" "Qu empresas han escrito una implementacin basada en una de estas interfaces?"

"Qu servicios Web, categorizados de algn modo, se ofrecen actualmente?" "Qu servicios Web ofrece una empresa determinada?" "Con quin se debe poner en contacto el usuario para utilizar los servicios Web de una empresa?" "Cules son los detalles de implementacin de un servicio Web concreto?" WSDL y UDDI WSDL se ha convertido en una pieza clave de la pila de protocolos de los servicios Web. Por eso, es importante saber cmo colaboran UDDI y WSDL y por qu la idea de interfaces frente implementaciones forma parte de cada protocolo. WSDL y UDDI se disearon para diferenciar claramente los metadatos abstractos y las implementaciones concretas. Para entender cmo funcionan WSDL y UDDI resulta esencial comprender las consecuencias de esta divisin. Por ejemplo, WSDL distingue claramente los mensajes de los puertos: los mensajes (la sintaxis y semntica que necesita un servicio Web) son siempre abstractos, mientras que los puertos (las direcciones de red en las que se invoca al servicio Web) son siempre concretos. No es necesario que un archivo WSDL incluya informacin sobre el puerto. Un archivo WSDL puede contener simplemente informacin abstracta de interfaz, sin facilitar datos de implementacin concretos, y ser vlido. De este modo, los archivos WSDL se separan de las implementaciones. Una de las consecuencias ms interesantes de esto es que pueden existir varias implementaciones de una nica interfaz WSDL. Este diseo permite que sistemas dispares escriban mplementaciones de la misma interfaz, para garantizar as la comunicacin entre ellos. Si tres empresas diferentes implementan el mismo archivo WSDL y una parte del software de cliente crea el cdigo auxiliar/proxy a partir de esa interfaz, dicho software se podr comunicar con las tres implementaciones con el mismo cdigo de base, cambiando simplemente el punto de acceso. UDDI establece una distincin similar entre la abstraccin y la implementacin con el concepto de tModels. La estructura tModel, abreviatura de "Technology Model" (modelo de tecnologa), representa huellas digitales tcnicas, interfaces y tipos abstractos de metadatos. El resultado de los tModels son las plantillas de enlace, que son la implementacin concreta de uno o ms tModels. Dentro de una plantilla de enlace se registra el punto de acceso de una implementacin particular de un tModel. Del mismo modo que el esquema de WSDL permite separar la interfaz y la implementacin, UDDI ofrece un mecanismo que permite publicar por separado los tModels de las plantillas de enlace que hacen referencia a ellos. Por ejemplo, un grupo industrial o de estndares publica la interfaz cannica para un sector particular y, a continuacin, varias empresas escriben implementaciones de esta interfaz. Obviamente, cada una de estas implementaciones hara referencia al mismo tModel. Los archivos WSDL constituyen un ejemplo perfecto de tModel de UDDI. Registro en UDDI La publicacin en UDDI es un proceso relativamente sencillo. El primer paso consiste en determinar informacin bsica sobre cmo definir la empresa y los servicios en UDDI. El siguiente paso, una vez determinada esta informacin, consiste en llevar a cabo el registro, ya sea mediante programacin o a travs de una interfaz de usuario basada en el

Web. Por ltimo, se debe probar la entrada para asegurar que se registr correctamente y que aparece tal y como se esperaba en diferentes tipos de bsquedas y herramientas. Primer paso: Definir la entrada de UDDI Partiendo del modelo de datos descrito anteriormente, se debe recopilar cierta informacin importante antes de establecer una entrada de UDDI. Determine los tModels (archivos WSDL) que utilizan las implementaciones del servicio Web. Al igual que sucede en el desarrollo de un componente COM, el servicio Web se ha desarrollado a partir de una interfaz existente o de una interfaz de diseo propio. En el caso de un servicio Web basado en una interfaz WSDL existente, deber determinar si el archivo WSDL se ha registrado en UDDI. Si es as, deber comprobar su nombre y tModelKey, que es el identificador GUID que gener UDDI cuando se produjo el registro. Por el contrario, si el servicio Web se basa en un archivo WSDL que no se ha registrado en UDDI, deber crear un nuevo tModel para representar esta interfaz. El nombre de este tModel debera tener un formato URI (identificador de recursos uniforme), como MyCompany- com:SampleWebService-interface:v1, y sealar a la ubicacin del archivo WSDL. Si su servicio Web es un servicio de Microsoft Visual Studio .NET, podr generar una descripcin WSDL utilizando una cadena de consulta desde el archivo .ASMX (como ). No obstante, el archivo WSDL generado por Visual Studio .NET se relaciona estrechamente con el punto de acceso para la invocacin del servicio Web, lo cual puede no resultar adecuado cuando la interfaz del servicio tiene varias implementaciones. Esto no supondr ningn problema si su intencin es que el archivo WSDL slo tenga una implementacin. Determine el nombre de la empresa y una breve descripcin de la misma en varios idiomas, si es necesario, as como los contactos principales para los servicios Web que ofrece. UDDI es compatible con el espacio de nombre xml:lang, lo que permite a las empresas ofrecer su descripcin en varios idiomas. Asimismo, UDDI permite enumerar los contactos, incluyendo datos como el correo electrnico, el telfono y la direccin. Esta lista de contactos muestra los recursos de una empresa con los que se puede poner en contacto en relacin con los servicios Web ofrecidos. Por ejemplo, si un usuario desea comenzar a utilizar el servicio Web deber ponerse en contacto con el responsable de relaciones comerciales correspondiente pero, cmo puede llegar a saber quin es? Existe algn contacto para obtener asistencia tcnica a la hora de utilizar los servicios Web de la empresa? Tambin se debera incluir en la lista a esta persona. Determine las categoras e identificaciones adecuadas para la empresa. Podr explorar los sistemas taxonmicos compatibles con UDDI actualmente en el nodo Microsoft UDDI (http://uddi.microsoft.com/default.aspx [en ingls]). Estos sistemas son, por el momento, North American Industry Classification System (NAICS), Universal Standard Products and Services Codes (UNSPSC), ISO 3166, Standard Industry Classification (SIC) y GeoWeb Geographic Classification. Seleccione las categoras que representan de forma ms acertada a su empresa. Determine los servicios Web que la empresa ofrece a travs de UDDI.

A continuacin, deber determinar los servicios Web que desea registrar la empresa en el nodo pblico UDDI. Existen varios puntos de acceso para este servicio? Es preciso que los clientes conozcan otros parmetros y otra informacin para utilizar el servicio Web? Resulta importante destacar que no todo el mundo puede obtener acceso a un servicio Web porque ste se haya registrado en UDDI. A una entrada de registro UDDI le pueden acompaar medidas de seguridad, autorizacin y autenticacin. No basta que el usuario sepa que existe un servicio Web para que pueda invocarlo. Puede existir una comunicacin fuera de banda entre empresas antes de permitir el acceso a un servicio Web. Determine las categoras adecuadas para los servicios. Los servicios Web se pueden categorizar del mismo modo que las empresas. No obstante, una empresa se debe categorizar a nivel empresarial, como por ejemplo NAICS: Software Publisher (51121), y el servicio Web (de reserva hotelera, en este caso) se debera categorizar en el nivel de servicios, como NAICS: Hotels and Motels (72111). Segundo paso: Registrar la entrada de UDDI Una vez finalizada la tarea de definicin, el siguiente paso consiste en registrar la empresa. Deber obtener una cuenta con un registro UDDI. Esta operacin no se puede realizar mediante programacin, ya que deber mostrar su conformidad con una declaracin de condiciones de uso. El nodo de Microsoft utiliza Passport para la autenticacin, as que deber adquirir una cuenta de Passport (http://www.passport.com/Consumer/default.asp) para continuar con el registro. En este punto se ofrecen dos opciones: puede utilizar la interfaz de usuario Web del nodo de Microsoft o realizar el registro mediante programacin dirigiendo al propio nodo las llamadas a API de SOAP. Si no piensa modificar la entrada o sta es relativamente simple, bastar con la interfaz de usuario Web. No obstante, si pretende actualizar la entrada con frecuencia, o bien, sta es ms compleja, resulta recomendable realizar el proceso de registro con secuencias de comandos, utilizando el SDK de Microsoft UDDI. Adems, la interfaz de usuario de Microsoft no est localizada en otros idiomas, as que se deber registrar mediante programacin para disfrutar esa caracterstica de la API de UDDI. Tercer paso: Buscar la entrada en UDDI Es recomendable realizar tres comprobaciones una vez registrada la entrada en UDDI. En primer lugar, utilizando la interfaz de usuario Web de Microsoft, busque la empresa por su nombre y categorizaciones para verla entre los conjuntos de resultados devueltos. En segundo lugar, abra Visual Studio .NET y asegrese de que aparece en el cuadro de dilogo "Agregar referencia Web". Si no aparece, se puede deber a que el tModel no se categoriz correctamente utilizando la taxonoma uddi-org:types descrita anteriormente. Podr agregar el servicio Web al proyecto y generar el cdigo proxy basado en el archivo WSDL. Por ltimo, transcurridas 24 horas, la entrada se replicar al nodo de IBM y podr buscarla con su IU en https://www-3.ibm.com/services/uddi/protect/find (en ingls). Para Terminar

UDDI y WSDL funcionan como especificaciones gratuitas que facilitar el desarrollo de una coleccin de software basado en servicios Web. WSDL ofrece un modo formal de definir servicios Web, independientemente del proveedor, que permitir realizar llamadas a procedimientos remotos de prxima generacin, mientras que UDDI proporciona una amplia infraestructura estandarizada que permite al usuario describir y descubrir servicios Web. Mediante la combinacin de estos dos estndares, se podr desarrollar todo un universo de servicios Web. Son seguros los Servicios Web XML? Teniendo en cuenta todos los aspectos de seguridad, autenticacin y autorizacin, confidencialidad e integridad de datos, etc., y el hecho de que la especificacin SOAP ni siquiera menciona la seguridad, es fcil llegar a la conclusin de que la respuesta es negativa. Pero no hay que subestimar los servicios Web XML de Microsoft. Hoy en da, se pueden tomar muchas medidas para crear servicios Web XML seguros. A la hora de tratar la seguridad en servicios Web XML, es necesario considerar los siguientes puntos: Cul es nuestro objetivo? Limitar el acceso a servicios Web XML a usuarios autorizados, evitar que los mensajes puedan ser visualizados por personas no autorizadas, etc. Cmo vamos a cumplir con el objetivo deseado? Red, capa de transporte, sistema operativo, servicio o aplicacin. Qu nivel de interoperabilidad deseamos y necesitamos en nuestra solucin? Local o global. Cmo se puede aumentar la seguridad de los servicios Web XML actuales? Esto se consigue respondiendo a las preguntas anteriores y, a continuacin, aplicando las mismas tcnicas de seguridad que utilizaramos para cualquier otra aplicacin Web: Crear conexiones seguras Autenticar y autorizar la interaccin

Como podr comprobar seguidamente, estas tcnicas ofrecen varias opciones que se pueden combinar para obtener beneficios adicionales. Por ejemplo, un servidor de seguridad puede funcionar con servicios Web XML para limitar el acceso a ciertas funcionalidades (mtodos) basndose en la identidad del cliente y las directivas definidas para cada cliente. Vamos a empezar repasando y entendiendo el funcionamiento de cada una de las opciones disponibles actualmente para crear una infraestructura segura. Creacin de una infraestructura segura una infraestructura segura es la clave para contar con servicios Web XML seguros. Microsoft ofrece una amplia gama de tecnologas que, una vez integradas en un plan general de seguridad, permiten a las empresas proteger eficazmente una infraestructura informtica. Para completar la implementacin con xito, la planeacin debe considerar lo siguiente: Tener una idea detallada de los riesgos potenciales del entorno (como virus, intrusos y desastres naturales. Realizar un anlisis activo de la relacin entre las consecuencias y contramedidas de una intrusin y los riesgos.

Crear una estrategia de implementacin planeada con detenimiento para integrar las medidas de seguridad en el conjunto de una red empresarial, basndose en los dos puntos anteriores. Creacin de conexiones seguras

Uno de los mtodos ms sencillos para aumentar la seguridad de los servicios Web XML consiste en asegurarse de que la conexin entre el cliente de servicios Web XML y el servidor es segura. Esto se puede llevar a cabo mediante varias tcnicas, dependiendo de la extensin de la red y el perfil de actividades de las interacciones. Tres de las tcnicas ms comunes y accesibles son: reglas basadas en un servidor de seguridad, SSL (Secure Sockets Layer) y redes privadas virtuales (VPN). Si sabe con exactitud qu equipos van a tener acceso a los servicios Web XML, puede utilizar reglas de servidor de seguridad para restringir el acceso a equipos con direcciones IP conocidas. Esta tcnica resulta particularmente til si desea restringir el acceso a equipos en una red privada virtual (por ejemplo, una red LAN/WAN corporativa) y no desea mantener el contenido de los mensajes en secreto (cifrados. Los servidores de seguridad, como Microsoft Internet Security and Acceleration (ISA) Server, pueden ofrecer reglas avanzadas basadas en directivas que roporcionen distintas restricciones para clientes diferentes segn su origen o identidad. Esto resulta de gran utilidad cuando se espera que determinados clientes tengan acceso a funcionalidades (mtodos) diferentes de los mismos servicios Web XML. Se puede utilizar SSL para establecer conexiones seguras en redes que no son de confianza (como Internet. SSL cifra y descifra mensajes enviados entre el cliente y el servidor. Al cifrar los datos, se evita que los mensajes sean ledos por terceros durante la transmisin. SSL cifra el mensaje del cliente y, a continuacin, lo enva al servidor. Una vez que el servidor lo recibe, SSL lo descifra y comprueba que procede del remitente correcto (proceso que se denomina autenticacin. El servidor, o el servidor y el cliente, pueden tener certificados que se utilizan como parte del proceso de autenticacin y que proporcionan capacidades de autenticacin adems del cifrado de la conexin. Aunque es un mtodo muy eficaz para crear comunicaciones seguras, SSL presenta un coste en rendimiento que debe tenerse en cuenta. Los servicios Web XML de Microsoft admiten SSL integrado, tanto en clientes como en servidores. Una red privada virtual es la extensin de una red privada que se conecta a travs de redes compartidas o pblicas, como Internet. Las redes virtuales privadas permiten enviar datos entre dos equipos en una conexin segura. Si bien su funcionamiento es similar a SSL, una red virtual segura es una conexin punto a punto establecida a largo plazo. De este modo, mejora la eficacia y permite la comunicacin con servicios Web XML, pero requiere que se establezca una conexin duradera a largo plazo para obtener un rendimiento mayor. Seguridad en servicios web. Autenticacin y autorizacin. Interoperabilidad 2 Autenticacin y autorizacin 2.1 Autenticacin: 2.2 La autenticacin es el proceso por el que se comprueba la identidad de alguien o algo, para ver si es lo que dice ser. Ese "alguien" o "algo" se denomina principal. La

autenticacin requiere pruebas de identidad, denominadas credenciales. Por ejemplo, una aplicacin cliente puede presentar una contrasea como sus credenciales. Si la aplicacin cliente presenta las credenciales correctas, se asume que es quien dice ser. 2.2 Autorizacin: Una vez que se ha autenticado la identidad de un principal, deben tomarse decisiones sobre la autorizacin. El acceso se determina comparando la informacin del principal con informacin de control de acceso, como listas de control de acceso (ACL. Es posible que los clientes tengan distintos grados de acceso. Por ejemplo, algunos clientes pueden tener acceso total a los servicios Web XML, mientras que otros estaran autorizados slo a ciertas operaciones. A algunos clientes se les permitir un acceso total a todos los datos, mientras que a otros slo se les permitir acceso a un subconjunto de los datos y otros tendrn acceso de slo lectura. Bsica: utilizada para identificacin no segura o poco segura de clientes, ya que el nombre de usuario y la contrasea se envan como texto codificado en base 64, que puede ser fcilmente descodificado. IIS autorizar el acceso a los servicios Web XML si las credenciales coinciden con las de una cuenta de usuario vlida. Bsica sobre SSL: igual que la autenticacin bsica, excepto que el canal de comunicacin est cifrado y protege de ese modo el nombre de usuario y la contrasea. Una buena opcin para entornos en Internet; sin embargo, el uso de SSL influye negativamente en el rendimiento. Implcita: utiliza algoritmos hash para transmitir las credenciales del cliente de forma segura. Sin embargo, es posible que no sea compatible con todas las herramientas de desarrollo para generar clientes de servicios Web XML. IIS autorizar el acceso a los servicios Web XML si las credenciales coinciden con las de una cuenta de usuario vlida. Autenticacin de Windows integrada: resulta til sobre todo en entornos en Intranet.Utiliza HTLM o Kerberos. El cliente debe pertenecer al mismo dominio que el servidor o a un dominio en el que el dominio del servidor confa. IIS autorizar el acceso a los servicios Web XML si las credenciales coinciden con las de una cuenta de usuario vlida. Certificados de cliente a travs de SSL: requiere que cada cliente obtenga uncertificado. Los certificados se asignan a las cuentas de usuario, que son utilizadas por IIS para autorizar el acceso a los servicios Web XML. Se trata de una solucin viable para entornos en Internet, aunque el uso de certificados digitales no est muy extendido actualmente. Es posible que no sea compatible con todas las herramientas de desarrollo para generar clientes de servicios Web XML. Slo est disponible en conexiones SSL, de modo que el rendimiento puede verse afectado. Desde la perspectiva de alguien que intenta implementar servicios Web XML, una de las ventajas de utilizar estos mecanismos de autenticacin es que no se necesita escribir nuevo cdigo. IIS/ISA Server completa todo el proceso de autenticacin y autorizacin ACL antes de llamar a los servicios Web XML. Sin embargo, al implementar el cliente ser necesario realizar algunas tareas adicionales. La aplicacin cliente necesitar responder a las peticiones de autenticacin y credenciales del servidor. Entre los mtodos para la implementacin de autenticacin en servicios Web XML tambin se incluyen servicios de terceros, como los que se encuentran en Microsoft .

NET Passport, caractersticas de sesin de Microsoft ASP.NET o la creacin de mtodos de autenticacin personalizados. 3 Prximamente: Interoperabilidad Como puede ver, las tcnicas habituales para crear aplicaciones Web seguras se pueden aplicar por separado o combinadas a la hora de proteger servicios Web XML. Estas tcnicas ya se han utilizado en el pasado y resultan bastante efectivas. Sin embargo, no ofrecen una solucin integrada dentro de la arquitectura de servicios Web XML. Conforme aumenta la complejidad del entorno de servicios Web XML (sobrepasando los lmites de la confianza, extendindose a mltiples sistemas o empresas) los responsables de implementarlos tienen que recurrir a soluciones personalizadas que, si bien resultan eficaces, no ofrecen una interoperabilidad total. Para hacer frente a estas necesidades y mejorar la interoperabilidad entre servicios Web XML, Microsoft y sus socios estn trabajando en un conjunto de especificaciones de seguridad basadas en el mecanismo de extensibilidad de la especificacin SOAP para ofrecer funciones de seguridad mejoradas e integradas en el ncleo mismo de los servicios Web XML. Una de las principales especificaciones que se estn desarrollando es el lenguaje de seguridad de servicios Web XML (WS-Security) que proporciona mejoras en la mensajera SOAP, consistentes en tres funcionalidades: transferencia de credenciales, integridad de mensajes y confidencialidad. Estas funcionalidades no proporcionan por s mismas una solucin de seguridad completa; WS-Security es una pieza que se puede utilizar en conjuncin con la infraestructura y otros protocolos de servicios Web XML para hacer frente a un gran nmero de requisitos de seguridad de aplicaciones. La arquitectura de servicios Web XML globales de Microsoft alberga a WS-Security y otras especificaciones relacionadas y proporciona un marco para la evolucin de la infraestructura de los servicios Web XML. El Futuro de los Servicios Web XML El mundo de los servicios Web est evolucionando a gran velocidad. En los ltimos tres aos, las especificaciones de los Servicios Web han sido definidas, refinadas y a veces, criticadas; se han lanzado kits de herramientas de servicios Web y los desarrolladores los han utilizado para construir sistemas, y los fabricantes han trabajado para garantizar la interoperabilidad. Al igual que con la infraestructura Web clsica, se est desarrollando e implantando tecnologas de servicios Web en paralelo, progresando a travs de un ciclo de realimentacin positivo. Aunque los servicios Web han progresado mucho en los ltimos tres aos, el trabajo sobre la plataforma contina. Si vamos a desarrollar sistemas basados en servicios Web, es importante comprender dnde est la plataforma hoy y cual va a ser el futuro. 1 Servicios Web hoy Actualmente, la plataforma de servicios Web ha sido desarrollada lo suficiente para crear aplicaciones distribuidas que se comunican enviando mensajes SOAP sobre HTTP. Esto no significa que no existan herramientas o marcos de trabajo de servicios Web que puedan hacer ms cosas (por ejemplo, enviar mensajes SOAP sobre SMTP. Sin embargo, la mensajera basada en HTTP es la nica opcin de comunicacin ms generalmente

soportada. La mayora de las herramientas de Servicios Web mapea mensajes SOAP a invocaciones de mtodos en objetos. Algunas proporcionan adems un acceso directo al cuerpo de los mensajes SOAP, exponindolos como XML. Servicios de alto nivel como la seguridad se implementan generalmente de modo ad hoc, tpicamente en el nivel de los protocolos de transporte. La mayora de los kits de herramientas de Servicios Web interoperan bastante bien, especialmente si nos limitamos a formatos de mensajes relativamente sencillos. Los miembros de la comunidad SOAPBuilders han realizado grandes mejoras sobre interoperabilidad organizando evaluaciones de SOAP y WSDL, y reunindose peridicamente para garantizar que sus kits de herramientas trabajan conjuntamente. Muchos de los trabajos de la comunidad SOAPBuilders han sido necesarios en relacin con varios aspectos de las especificaciones SOAP 1.1 y WSDL 1.1. El W3C dispone de grupos de trabajo focalizados en refinar ambas especificaciones, lo que debera aportar mejoras sustanciales. El grupo XML Protocol Working Group est trabajando en la especificacin SOAP 1.2 mientras que el grupo Web Services Description Working Group est creando la especificacin WSDL 1.2. Mientras tanto, IETF y OASIS estn tambin trabajando en estandarizar especificaciones de servicios Web, incluyendo DIME y WS-Security. Mientras que el trabajo en el W3C se centra en las nuevas versiones de las especificaciones del ncleo de los servicios Web, existe otra organizacin independiente que est prestando ms tencin a la interoperabilidad. La organizacin Web Services Interoperability Organization (WS-I) tiene como objetivo definir mejores prcticas para garantizar la interoperabilidad de los servicios Web. El grupo WS-I Basic Profile Working Group est actualmente desarrollando un conjunto de recomendaciones sobre cmo utilizar los protocolos bsicos de los servicios Web como SOAP 1.1 y WSDL 1.1 para maximizar la interoperabilidad. 2 Servicios Web en el futuro El trabajo sobre la plataforma de servicios Web continuar en el futuro, y aparecern mejoras en tres reas fundamentales. En primer lugar, se aadirn servicios de ms alto nivel. Todo el mundo est de acuerdo en que debe existir un modo estndar de asegurar servicios Web, rutear mensajes, garantizar una entrega fiable de mensajes, definir semntica transaccional, etc. Estas caractersticas de propsito general se expanden ms all de los dominios del problema y no hay ninguna razn por la que cada desarrollador de servicios Web deba implementarlas individualmente. Microsoft, IBM y otros estn realizando mucho trabajo en estas reas. La iniciativa Global XML Web Service Architecture (GXA) define un conjunto de especificaciones sobre cmo implementar estos servicios de infraestructura en trminos de mensajes SOAP (por ejemplo, de un modo neutral respecto del protocolo de transporte. En segundo lugar, seguirn estandarizndose especificaciones. El ciclo de vida de las especificaciones de servicios Web tpicamente progresa desde una propuesta hasta un estndar de facto y desde ste hasta un estndar real. Con SOAP 1.2 y WSDL 1.2 las peculiaridades finales estn siendo elaboradas de las especificaciones SOAP y WSDL y algunas de las especificaciones de servicios de mayor nivel, como WS-Security, ya estn en el periodo "de facto" en el proceso de estandarizacin. Las empresas siguen proponiendo nuevas especificaciones como aadidos a la plataforma de servicios Web y

la industria en su conjunto necesitar acordar cules adoptar. Esas especificaciones necesitarn a continuacin ser estandarizadas. En tercer lugar, los kits de herramientas y marcos de trabajo seguirn mejorando. Adems de servicios de ms alto nivel como la seguridad y los objetos adjuntos, se aadir soporte para protocolos de transporte alternativos como SMTP o TCP. De modo ms importante, los modelos de programacin migrarn desde los servicios de tipo RPC hacia servicios centrados en documentos, para promover un acoplamiento dbil. Todos estos cambios ocurrirn en paralelo, mientras los desarrolladores continan desarrollando e implantando sistemas basados en servicios Web. 3 Avances de futuro Llegados a este punto, estaremos preguntndonos cmo podemos utilizar los servicios Web cuando la plataforma todava est evolucionando. Las herramientas y marcos de trabajo de los servicios Web actuales proporcionan suficiente funcionalidad bsica para desarrollar interesantes aplicaciones distribuidas que envan mensajes SOAP sobre HTTP. Algunos servicios de mayor nivel como WS-Security estn empezando a cuajar con el soporte de diversas herramientas nuevas como el kit Web Services Development Kit. Otros servicios estn todava en fase de desarrollo preliminar a medida que las especificaciones se van revisando y las primeras implementaciones exponen reas en las que las especificaciones necesitan solidificarse. Mientras tanto, podemos apoyarnos en mecanismos HTTP tradicionales para implementar seguridad y dems caractersticas. Si queremos desarrollar servicios Web utilizando herramientas de Microsoft, tenemos varias opciones. Si todava estamos utilizando Visual Studio 6.0 o algn otro entorno de desarrollo que no soporta el desarrollo de cdigo gestionado, podemos crear y consumir servicios Web utilizando el kit de herramientas SOAP Toolkit. Si estamos utilizando .NET, podemos focalizarnos en los mtodos Web de ASP.NET (a esto hace referencia la mayor parte de la documentacin de .NET sobre los servicios Web). En cualquier caso, podemos aprender tanto como queramos sobre cmo funcionan los protocolos de mensajera y metadatos de los servicios Web. Cuanto ms comprendamos la fontanera, ms fcil ser desarrollar nuestros propios servicios y utilizar servicios desarrollados por los dems. Tambin podemos experimentar con las nuevas especificaciones. La versin preliminar del kit Microsoft WSDK Technology Preview proporciona un soporte preliminar para las especificaciones WS-Security, WS-Routing y DIME. Podemos tambin implementar especificaciones por nosotros mismos, tanto utilizando extensiones sobre uno de los marcos de trabajo o kits de herramientas (por ejemplo, SoapExtensions en ASP.NET), como crear nuestra propia pila SOAP utilizando XML plano y las APIs HTTP. Esta opcin no es para todo el mundo, pero si tenemos tiempo y recursos, obtendremos pronto una avanzada funcionalidad. Adems, contribuiremos al desarrollo de la plataforma. El entendimiento colectivo de SOAP Y WSDL se mejor sustancialmente gracias al intento de implementacin de sistemas basados en ambos estndares por parte de mltiples usuarios. Cuanto ms estrechamente trabajen los usuarios con las nuevas especificaciones, mejor resultar la plataforma de servicios Web global.