Servicios Web .Net

Introdución a los servicios web “Toda la información disponible para cualquier persona, en cualquier lugar, a través de cualquier dispositivo.” Esta frase acuña quizás el sueño de todos los que de una u otra forma se relacionan con las tecnologías de la información, partiendo desde una gran compañía tecnológica hasta un simple usuario de una planilla Excel. La pregunta es: ¿Será esto posible? A mediado de la década de los 90 y con la aparición de Internet y su posterior masificación a niveles jamás pensados, ha existido siempre la necesidad e inquietud por parte de las empresasdesarrolladoras de software de buscar o contar con la manera de lograr la integración entre sistemas heterogéneos, cuando hablo de sistemas heterogéneos me refiero tanto al software como al hardware. Para tal efecto muchas compañías fueron creando de forma individual la mejor manera de lograr esta integración. Muchas empresas comenzaron una loca carrera para generar la mejor tecnología integradora de sistemas, pero a medida que la competencia se hacia cada vez más fuerte, la integración se hacia cada vez más difícil. Debido a la gran masificación de Internet a niveles insospechables y al gran impacto causado por las tecnologías de la información en las ultimas dos décadas del siglo pasado, la manera de hacer negocios y la comunicación entre las personas y las empresas cambió de una manera rotunda. Bajo este contexto se hacía cada vez mayor la necesidad de integrar y compartir información 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 raíz. Para esto decidieron que en vez de crear la mejor plataforma integradora, era mejor buscar un leguaje común de intercambio de información aprovechando los estándares existentes en el mercado. Bajo este contexto nacen los Servicios Web basados en XML, 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 práctica la adopción e implementación de dicha tecnología, también conocer sus principales ventajas así como sus limitaciones desde un punto de vista de una tecnología que esta en continuo desarrollo. Dimensionar los nuevos cambios de paradigmas informáticos producto de la implementación de Servicios Web. Esto quiere decir poder dimensionar que esta tecnología viene a cambiar la forma en que se comunicaban las distintas aplicaciones y la forma en que se accede a la información que reside en distintas plataformas y aplicaciones desde diversos tipos de equipos y dispositivo de comunicación. Ampliar el conocimiento de todas las tecnologías asociadas a los Servicios Web.

Servicios Web en plataforma .NET

Manual por: DesarrolloWeb.com [http://www.desarrolloweb.com/]"Tu mejor ayuda para aprender a hacer webs"

Versión on-line:http://www.desarrolloweb.com/manuales/54

Página 1 de 52Servicios Web en plataforma .NET - Manual completo

De manera general o detallada conocer las tecnologías asociadas a Servicios Web. Ya que de alguna manera, más 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 tecnología. La intención del presente documento no es solo la de explicar el contexto de los Servicios Web, si no también transmitir al lector un numero de nuevos conceptos y tecnologías que en la actualidad están en pleno desarrollo y en adopción 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 informática se refiere.

Una visión general I Web Services y la evolución hacia la Economía Global Las aplicaciones web actuales ya no son suficientes. El modelo actual de negocio electrónico no facilita la integración de las aplicaciones de Internet con el resto de software de las empresas. Si las compañías quieren extraer el máximo beneficio de Internet, los sitios web deben evolucionar. Este es el contexto en el que surgen los web services. Los web services son componentes software que permiten a los usuarios usar aplicaciones de negocio que comparten datos con otros programas modulares, vía Internet. Son aplicaciones independientes de la plataforma que pueden ser fácilmente publicadas, localizadas e invocadas mediante protocolos web estándar, como XML, SOAP, UDDI o WSDL. El objetivo final es la creación de un directorio online de 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 aplicación 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 comunicación 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 publicación y localización de los servicios. Los directorios UDDI actúan como una guía telefónica de web services.

Aunque la idea de la programación modular no es nueva, el éxito de esta tecnología reside en que se basa en estándares conocidos en los que ya se tiene una gran confianza, como el XML. Además, el uso de los web services aporta ventajas significativas a las empresas. El principal objetivo que se logra, es la interoperabilidad y la integración. Mediante los web services, las empresas pueden compartir servicios software con sus clientes y sus socios de negocio. Esto ayudará a las compañías a escalar sus negocios, reduciendo el coste en desarrollo y mantenimiento de software, y sacando los productos al mercado con mayor rapidez. La integración de aplicaciones hará posible obtener la información demandada en tiempo real, acelerando el proceso de toma de decisiones. La evolución de Internet hacia los web services, mejorará los resultados globales de las empresas, reduciendo sus gastos y guiándolas hacia unamejora progresiva de la calidad. La adopción de la tecnología de servicios web por la industria es el primer paso hacia una economía global. Posibles riesgos Las expectaciones alrededor de esta tecnología son grandes, porque el mercado de aplicación


es muy amplio. Pero también tiene sus puntos oscuros:

Los web services hacen uso de las mismas tecnologías que han sido atacadas en tantas ocasiones. Usando web services, la seguridad de una empresa puede verse comprometida. La ausencia de técnicas de seguridad estándar es un obstáculo para la adopción de la tecnología. La calidad de un web service es un parámetro que no queda demasiado claro, pero cuya medida es fundamental a la hora de desarrollar un servicio maduro.

Una visión general II Seguridad Actualmente, los web services están 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 compañía. Los desarrollos actuales no ayudan a la cooperación entre las empresas ya que no hay ningún estándar establecido sobre las técnicas de seguridad. Debido a la tecnología que es usada por los web services, y en concreto al uso de SOAP, las técnicas de seguridad convencionales que se han venido usando en Internet, ya no son suficientes. Con SOAP, cada mensaje simple que se intercambia realiza múltiples saltos y es rutado a través de numerosos puntos antes de que alcance su destino final. Es por ello que los web services necesitan tecnologías que protejan los mensajes desde el principio hasta el final. Existen un conjunto de técnicas que se pueden usar para garantizar la seguridad a nivel de mensaje. Estas son:

Encriptación XML: Evita que los datos se vean expuestos a lo largo de su recorrido. Firma Digital XML: Asocia los datos del mensaje al usuario que emite la firma, de modo que este usuario es el único que puede modificar dichos datos. XKMS 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 Autorización: SAML (Security Assertion Mark-up Language) hace posible que los web services intercambien información de autentificación y autorización entre ellos, de modo que un web service confíe en un usuario autentificado por otro web service. Validación de datos: Permite que los web services reciban datos dentro de los rangos esperados.

Además, también hay técnicas que permiten mantener la seguridad a otros niveles. La seguridad en UDDI permite autentificar todas las entidades que toman parte en la publicación 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 específicamente diseñadas para medir la calidad de los web services, pero sigue siendo necesaria una estandarización sobre este tema. Los resultados sobre la calidad de diferentes web services, servirán como parámetro de comparación y ayudarán al consumidor a decantarse por un servicio u otro. Para que un web service se ejecute con corrección y satisfaga las expectativas creadas, a parte del precio, habrá que tener en cuenta una serie de parámetros como por ejemplo, que los resultados obtenidos del mismo sean los esperados o que el entorno de uso sea amigable. Otro elemento a tener en cuenta es la integración. Aunque teóricamente los web services proporcionan conectividad con cualquier software de un modo transparente, cada proveedor de servicios puede adoptar soluciones diferentes que resultan más o menos adecuadas para el consumidor. Analizando la escalabilidad se comprobará el grado de modularidad y flexibilidad del servicio. Por último,


también sería interesante analizar las características que ofrece el proveedor de web services. Actualmente no hay definidos estándares sobre este tema, pero la mayoría de las empresas ya está demandando algún tipo de acuerdo o contrato con los proveedores, de modo que se pueda garantizar la calidad y la fiabilidad de los servicios por los que se paga. Estandarización Los web services están basados en el estándar XML, que ha sido universalmente aceptado. Pero la situación para el resto de protocolos es bien distinta. La mayor parte de ellos se encuentran todavía en desarrollo y pueden ser objeto de cambios. Esa es la razón por la que la mayoría de las empresas están esperando a que estos protocolos sean más universales antes de profundizar en esta tecnología. Actualmente, ni SOAP, ni WSDL, ni UDDI han sido oficialmente reconocidos por ningún organismo de estandarización. SOAP es el único que en este momento está en consideración por el World Wide Web Consortium y se encuentra cercano a la estandarización. SOAP y WSDL están siendo ampliamente usados, pero de momento UDDI no ha tenido el mismo éxito. El principal motivo es que las técnicas de seguridad son todavía muy inmaduras y las compañías prefieren hacer uso de registros privados para dar soporte a intercambios privados de web services. En febrero de este año, algunas de las empresas más importantes en el desarrollo de Negocio Electrónico como IBM, Intel, Microsoft o Oracle, han creado el WS-I: organización para la Interoperabilidad de los Web Services. El objetivo de dicha organización es la promoción de la estandarización de los web services de modo que se fomentela cooperación e interoperabilidad entre las compañías y mercados. Algunos ejemplos Las principales compañías del mundo han empezado a desarrollar soluciones mediante la tecnología 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 localización exacta y otros datos adicionales relacionados con su posición actual, como información de tráfico, rutas posibles o puntos comerciales cercanos. IBM: Ha implementado una solución basada en los web services llamada e-Business on Demand. Esta solución permite la construcción de Extranets que ayuden a las empresas a ver los catálogos de productos, realizar y localizar pedidos o chequear el estado del inventario en tiempo real. Líneas Aéreas Escandinavas: Estas líneas aéreas han desarrollado un servicio web que permite a los usuarios comprar billetes y chequear el estado de los vuelos, mediante el uso del teléfono móvil.

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, vía Internet. Son aplicaciones independientes de la plataforma que pueden ser fácilmente publicadas, localizadas e invocadas mediante protocolos web estándar, como XML, SOAP, UDDI o WSDL. El objetivo final es la creación de un directorio de online de web services, que pueda ser localizado de un modo sencillo y que tenga una alta fiabilidad." "Los servicios web son la revolución informática de la nueva generación de aplicaciones que trabajan colaborativamente en las cuales el software esta distribuido en diferentes servidores." "Los servicios XML Web son los bloques de construcción de la computación distribuida en el Internet. Usted puede crear soluciones al usar los múltiples servicios de XML Web desde varias fuentes que trabajan en conjunto-independientemente de dónde residan o cómo fueron implementadas."

XML Web Services


Antes de continuar y con el propósito de dejar al lector con una idea lo más clara posible acerca de el concepto de Web Services (Servicio Web), quiero citar una definición que rescate al asistir a una charla técnica de XML Web Service en Microsoft en octubre del 2003 cuyo expositor fue el señor 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 través de protocolos estándares 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 través de un mensaje formateado en XML desde una aplicación, realiza una tarea y devuelve un mensaje de respuesta también formateado en XML. Microsoft y otras empresas lideres están promocionando SOAP como estándar 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 dirección del receptor del mensaje , un conjunto de opciones de entrega (tal como la información de encriptación), y un cuerpo o body con la información o data del mensaje. Microsoft y otros proveedores líderes promocionan los Web Services como un modelo de programación para la comunicación entre aplicaciones. Estas compañías piensan que la conexión de aplicaciones a través de la Internet mejorará la capacidad de las empresas para trabajar conjuntamente con sus socios de negocio, proveedores y clientes. Creando una capa deWeb Services sobre una aplicación corporativa existente, las organizaciones podrán permitir que sistemas externos puedan invocar las funciones de la aplicación a través de Internet (o una intranet corporativa) sin tener que modificar la aplicación misma. Por ejemplo, varias compañías están hoy en día creando Web Services que actúan como front end para aplicaciones de entrada de órdenes que están residentes internamente en un mainframe. Estas compañías permiten a los sistemas de compras de sus clientes enviar órdenes de compra a través de la Internet. Poner una capa de web services sobre las aplicaciones existentes es una solución muy interesante para integrar las aplicaciones desarrolladas por los diferentes departamentos y así reducir los costos de integración." Ahora que ya tenemos una breve noción de lo que es un Web Services nos introduciremos en aspectos un poco más técnicos. Requisitos de un Web Service

Interoperabilidad: Un servicio remoto debe permitir su utilización por clientes de otras plataformas. Amigabilidad con Internet: La solución debe poder funcionar para soportar clientes queaccedan a los servicios remotos desde internet. Interfaces fuertemente tipadas: No debería haber ambigüedad acerca del tipo de dato enviado y recibido desde un servicio remoto. Más aún, los tipos de datos definidos en el servicio remoto deben poderse corresponder razonablemente bien con los tipos de datos de la mayoría de los lenguaje de programación procedimentales. Posibilidad de aprovechar los estándares de Internet existentes: La implementación del servicio remoto debería aprovechar estándares de Internet existentes tanto como sea posible y evitar reinventar soluciones a problema que ya se han resuelto. Una solución construida sobre un estándar de Internet ampliamente adoptado puede aprovechar conjuntos de herramientas y productos existentes creados para dicha tecnología. Soporte para cualquier lenguaje: La solución no debería ligarse a un lenguaje de programación particular Java RMI, por ejemplo, esta ligada completamente a lenguaje Java. Sería muy difícil invocar funcionalidad de un objeto Java remoto desde Visual Basic o PERL. Un cliente debería ser capaz de implementar un nuevo servicio Web existente independientemente del lenguaje de programación en el que se halla escrito el cliente Soporte para cualquier infraestructura de componente distribuida: La solución no debe estar fuertemente ligada a una infraestructura de componentes en particular. De


hecho, no se bebería requerir el comprar, instalar o mantener una infraestructura de objetos distribuidos, solo construir un nuevo servicio remoto utilizar un servicio existente. Los protocolos subyacentes deberían proporcionar un nivel base de comunicación 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

Descripción

WSDL, Esquema XML, Docs

Formato de Mensaje

SOAP

Codificación

XML

Transporte

HTTP,SMTP y otros

Figura II.1: "Bloques constructivos de Servicios Web"

Descubrimiento: La aplicación cliente que necesita acceder a la funcionalidad que expone un Servicio Web necesita una forma de resolver la ubicación 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 métodos ad hoc. En DCOM, el servicio de descubrimiento lo proporciona el Administrador de control de servicios (SCM, Services Control Manager). Descripción: Una vez que se ha resuelto el extremo de un servicio Web dado, el cliente necesita suficiente información para interactuar adecuadamente con el mismo. La descripción de un servicio Web implica meta datos estructurados sobre la interfaz que intenta utilizar la aplicación cliente así como documentación escrita sobré el servicio Web incluyendo ejemplo de uso. Un componente DCOM expone meta datos estructurados sobre sus interfaces mediante una biblioteca 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 programación de aplicación (API) propietaria. Formato del mensaje: Para el intercambio de datos, el cliente y el servidor tienen que estar de acuerdo en un mecanismo común de codificación y formato de mensaje. El uso de un mecanismo estándar de codificar los datos asegura que los datos que codifica el cliente los interpretará correctamente el servidor. En DCOM los mensajes que se envían entre un cliente y un servidor tienen un formato definido por el protocolo DCOM Object RPC (ORPC). Codificación: Los datos que se trasmiten entre el cliente y el servidor necesitan codificarse en un cuerpo de mensaje. Dcom utiliza un esquema de codificación binaria para serializar los datos de los parámetros 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 algún protocolo 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 documentación acerca de este primer protocolo de comunicación bajo http mediante XML. Con este protocolo se pedían realizar RPC o remote procedure calls, es decir, podíamos bien en cliente o servidor realizar peticiones mediante http a un servidor web. Los mensajes debían tener un formato determinado empleando XML para encapsular los parámetros de la petición. 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 interés porXML-RPC se desarrollo SOAP." En el núcleo de los servicios Web se encuentra el protocolo simple de acceso a datos SOAP, que proporciona un mecanismo estándar de empaquetar mensajes. SOAP ha recibido gran atención debido a que facilita una comunicación del estilo RPC entre un cliente y un servidor remoto. Pero existen multitud de protocolos creados para facilitar la comunicación entre aplicaciones, incluyendo RPC de Sum, DCE de Microsoft, RMI de Java y ORPC de CORBA. ¿Por qué se presta tanta atención a SOAP? Una de las razones principales es que SOAP ha recibido un increíble apoyo por parte de la industria. SOAP es el primer protocolo de su tipo que ha sido aceptado prácticamente por todas las grandes compañías de software del mundo. Compañías que en raras ocasiones cooperan entre sí están ofreciendo su apoyo a este protocolo. Algunas de las mayores Compañías que soportan SOAP son Microsoft, IBM, SUN, Microsystems, SAP y Ariba. Algunas de las Ventajas de SOAP son:

No esta asociado con ningún lenguaje: los desarrolladores involucrados en nuevos proyectos pueden elegir desarrollar con el ultimo y mejor lenguaje de programación que exista pero los desarrolladores responsables de mantener antiguas aflicciones heredadas podrían no poder hacer esta elección sobre el lenguaje de programación que utilizan. SOAP no especifica una API, por lo que la implementación de la API se deja al lenguaje de programación, como en Java, y la plataforma como Microsoft .Net. No se encuentra fuertemente asociado a ningún protocolo de transporte: La especificación de SOAP no describe como se deberían asociar los mensajes de SOAP con HTTP. Un mensaje de SOAP no es más 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 mayoría de los sistemas de objetos distribuidos se pueden extender, y ya lo están alguno de ellos para que admitan SOAP. Aprovecha los estándares existentes en la industria: Los principales contribuyentes a la especificación SOAP evitaron, intencionadamente, reinventar las cosas. Optaron por extender los estándares existentes para que coincidieran con sus necesidades. Por ejemplo, SOAP aprovecha XML para la codificación de los mensajes, en lugar de utilizar supropio sistema de tipo que ya están definidas en la especificación 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 múltiples entornos: SOAP se desarrollo sobre los estándares existentes de la industria, por lo que las aplicaciones que se ejecuten en plataformas con dicho estándares pueden comunicarse mediante mensaje SOAP con aplicaciones que se ejecuten en otras plataformas. Por ejemplo, una aplicación de


escritorio que se ejecute en una PC puede comunicarse con una aplicación del back-end ejecutándose en un mainframe capaz de enviar y recibir XML sobre HTTP.

Anatomía de un mensaje de SOAP SOAP proporciona un mecanismo estándar de empaquetar un mensaje. Un mensaje SOAP se compone de un sobre que contiene el cuerpo del mensaje y cualquier información de cabecera que se utiliza para describir le mensaje. A continuación tiene un ejemplo:

Figura III.1: "Anatomía de un mensaje SOAP"

El elemento raíz del documento es el elemento Envelope. El ejemplo contiene dos subelementos, Body y Header. Un ejemplo de SOAP valido también puede contener otros elementos hijo en el sobre. El sobre puede contener un elemento Header opcional que contiene información 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. Además de definir un sobre de SOAP, la especificación de SOAP define una forma de codificar los datos contenidos en un mensaje. La codificación de SOAP proporciona un mecanismo estándar para zerialisar tipos de datos no definidos en la parte 1 de la especificación del esquema de XML. La especificación de SOAP también proporciona un patrón de mensaje estándar para facilitar el comportamiento de tipo RPC. Se emparejan dos mensajes de SOAP para facilitar la asociación de un mensaje de petición con un mensaje de respuesta. La llamada a un método y sus parámetros se serializan en el cuerpo del mensaje de petición en forma de una estructura. El elemento raíz tiene el mismo nombre que el método objetivo, con cada uno de los parámetros codificado como un subelemento. El mensaje de respuesta puede contener los resultados de la llamada al método o una estructura de fallo bien definida. Los resultados de la llamada a un método se serializan en el cuerpo de la petición como una estructura. Por convenio, el elemento raíz tiene el mismo


nombre que el método original al que se añade result. Los parámetros de retorno se serializan como elementos hijo, con el parámetro 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 raíz tiene el mismo nombre que el método original al que se añade result. Los parámetros de retorno se serializan como elementos hijo, con el parámetro 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 intención explicar detalladamente la sintaxis de este lenguaje si no más bien no evocaremos a aspectos más generales como sus orígenes, sus características principales y porque es el lenguaje escogido para desarrolla servicios Web. Vista general de XML El código html permite insertar menús, tablas, imágenes 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 información comparativa en diferentes tiendas por ejemplo, pero nada más. Con XML el usuario podrá ordenar los datos o actualizarlos en tiempo real o realizar un pedido. La información que manejan las empresas es uno de sus principales activos. Pero lo normal es que esa información esté fragmentada, en diferentes departamentos, ordenadores conectados ono, etc. El reto ahora está en interrelacionar toda esa información para rendir todo su potencial y ponerlo a trabajar para aumentar los beneficios o reducir los costes. Para realizar esto se necesita un estándar de almacenamiento estructurado que es lo que nos ofrece XML. Una gran cantidad de gente ha oído hablar últimamente de XML y mucha gente que es una especie de HTML pero más avanzado. Pero todo el mundo lo que debería 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 más o menos claro es que XML es un lenguaje de Marcas, pero qué es exactamente un lenguaje de marcas. Lenguajes de Marcas En los años 60, IBM intentó resolver sus problemas asociados al tratamiento de documentos en diferentes plataformas a través de GML (Generalized markup Language. El principal problema era que cada aplicación utilizaba sus propias marcas para describir los diferentes elementos. Las marcas son códigos que indican a un programa cómo 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 demás características de cualquier texto. Ejemplos pueden tenerlos en mente los usuarios de WordPerfect. Conociendo este sistema y conociendo a la perfección el sistema de marcas de cada aplicación sería posible pasar información 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, código ASCII. Y la norma se denominó GML (General Modeling Language. Más 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 más conocidos son el HTML y el RTF. Los lenguajes de marcas no son equivalentes a los lenguajes de programación aunque se definan igualmente como "lenguajes". Son sistemas complejos de descripción de información, normalmente documentos, que si se ajustan a SGML, se pueden controlar desde cualquier editor ASCII. Las marcas más utilizadas suelen describirse por textos descriptivos encerrados entre signos de "menor" (<) y "mayor" (>), siendo lo más usual que existan una marca de principio y otra de final. Se puede decir que existen tres utilizaciones básicas de los lenguajes de marcas: los que sirven principalmente para describir su contenido, los que sirven más que nada para definir su formatoy 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 típicos del segundo tipo, y aunque no lo parezca, el HTML es la muestra más conocida del tercermodelo. ¿Qué es XML? XML, es el estándar de Extensible Markup Language. XML no es más que un conjunto de reglas para definir etiquetas semánticas que nos organizan un documento en diferentes partes. XML esun metalenguaje que define la sintaxis utilizada para definir otros lenguajes de etiquetas estructurados. En primer lugar para entenderlo bien hay que olvidarse un poco, sólo un poco de HTML. En teoría HTML es un subconjunto de XML especializado en presentación de documentos para la Web, mientras que XML es un subconjunto de SGML especializado en la gestión de información para la Web. En la práctica XML contiene a HTML aunque no en su totalidad. La definición de HTML contenido totalmente dentro de XML y por lo tanto que cumple a rajatabla la especificación SGML es XHTML (Extensible, Hypertext Markup Language. Desde su creación, 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 versión salió a la luz el 10 de febrero de 1998. La primera definición que apareció fue: Sistema para definir validar y compartir formatos de documentos en la web. Durante el año 1998 XML tuvo un crecimiento exponencial, y con ello me refiero a sus apariciones en medios de comunicación, menciones en páginas 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 fácil la escritura de programas que procesen documentos XML. El número de características opcionales en XML debe ser absolutamente mínimo, idealmente cero. Los documentos XML deben ser legibles por humanos y razonablemente claros. El diseño de XML debe ser preparado rápidamente. El diseño de XML debe ser formal y conciso. Los documentos XML deben ser fácilmente creables.


La concisión en las marcas XML es de mínima importancia. Esta especificación, junto con los estándares asociados (Unicode e ISO/IEC 10646 para caracteres, Internet RFC 1766 para identificación de lenguajes, ISO 639 para códigos de nombres de lenguajes, e ISO 3166 para códigos de nombres de países), proporciona toda la información necesaria para entender la Versión 1.0 de XML y construir programas de computador que los procesen.

Principales características

Es una arquitectura más 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 comparación a los atributos de la etiqueta del HTML. Integración de los datos de las fuentes más 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 múltiples aplicaciones. La extensibilidad y flexibilidad de este lenguaje nos permitirá agrupar una variedad amplia de aplicaciones, desde páginas web hasta bases de datos. Gestión y manipulación de los datos desde el propio cliente web. Los motores de búsqueda devolverán respuestas más adecuadas y precisas, ya que la codificación del contenido web en XML consigue que la estructura de la información resulte más accesible. Se desarrollarán de manera extensible las búsquedas personalizables y subjetivas para robots y agentes inteligentes. También conllevará que los clientes web puedan ser más autónomos para desarrollar tareas que actualmente se ejecutan en el servidor. Se permitirá un comportamiento más estable y actualizable de las aplicaciones web, incluyendo enlaces bidireccionales y almacenados de forma externa (El famoso epígrafe "404 file not found" desaparecerá). El concepto de "hipertexto" se desarrollará ampliamente (permitirá denominación independiente de la ubicación, enlaces bidireccionales, enlaces que pueden especificarse ygestionarse desde fuera del documento, hiperenlaces múltiples, enlaces agrupados, atributos para los enlaces, etc. Creado a través del Lenguaje de enlaces extensible (XLL). Exportabilidad a otros formatos de publicación (papel, web, cd-rom, etc.). El documento maestro de la edición electrónica podría ser un documento XML que se integraría en el formato deseado de manera directa.

Estructura del XML El metalenguaje XML consta de cuatro especificaciones (el propio XML sienta las bases sintácticas y el alcance de su implementación):

DTD (Document Type Definition) Definición del tipo de documento. Es, en general, un archivo/s que encierra una definición formal de un tipo de documento y , a la vez, especifica la estructura lógica de cada documento. Define tanto los elementos de una página como sus atributos. El DTD del XML es opcional. En tareas sencillas no es necesario construir una DTD, entonces se trataría de un documento "bien formado"(well-formed) 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 informáticas 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 múltiple columnas, texto girado, orden de visualización de los datos de una tabla, múltiples tipos de letra con amplia variedad en los tamaños. Este estándar está basado en el lenguaje de semántica y especificación de estilo de documento(DSSSL, Document Style Semantics and Specification Language, ISO/IEC 10179) y, por otro lado, se considera más 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 integración en XML con el protocolo CSS2 (Cascading Style Sheets, level 2) ofreciendo nuevas formas de composición y una más rápida visualización) y, por otra parte, XSL pueda ser utilizado donde se requiera más potencia de diseño 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 estructuración hipermedia/basado en el tiempo, ISO 10744) y sigue algunas especificaciones del TEI (Text Encoding Initiative o Iniciativa de codificación 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 más allá de los enlaces simples que sólo soporta el HTML. Se podrá implementar con enlaces extendidos. Jon Bosak establece los siguientes mecanismos hipertextuales que soportará esta especificación:

Denominación independiente de la ubicación. Enlaces que pueden ser también 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 automáticamente. No habrá más errores del tipo "404 Not Found"). Hiperenlaces múltiples (anillos, múltiples ventanas, etc.). Enlaces agrupados (múltiples orígenes). Transclusión (el documento destino al que apunta el enlace aparece como parte integrante del documento orígen del enlace). Se pueden aplicar atributos a los enlaces (tipos de enlaces). XUA (XML User Agent): Estandarización de navegadores XML. Todavía está en proceso de creación 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 más sobre XML no queda responde ¿porque XML es utilizado en los servicios Web? Si recapitulamos todo los capítulos anteriores seguro ya tendremos alguna pista para esta pregunta, pero para hacerlo más práctico diremos que se utiliza XML porque:

Es un estándar abierto es decir que es reconocido mundialmente ya que muchas compañías tecnológicas integran en sus software compatibilidad con dicho lenguaje. Esto quiere decir que la gran mayoría de software de escritorio de sistema operativo, aplicaciones móviles permiten la compatibilidad con XML esto lo hace muy potente a la hora de permite la comunicación 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 fácil de escribir código en XML y la representación 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 básicas y ya esta en condiciones de escribir código XML el cual será soportado o entendido por cualquier aplicación que pueda leer documentos XML. El hecho de que XML sea tan fácil 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 ningún 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 característica como lo son los mas conocidos en HTTP y SMTP por nombrar algunos. Volviendo la tema de los servicios Web una de las característica de estos es la independencia del protocolo de trasporte.


WSDL para la documentación de Servicios Web El esquema XML por sí solo no puede describir totalmente un Servicio Web. Supongamos que seha creado un servicio Web Calculadora. Este servicio Web expone los métodos sumar y restar. Ambos métodos 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 cómo interacciona un cliente con el servicio Web se define un esquema para los mensajes que se intercambiarán entre el cliente y el servidor. El esquema contiene una definición de un tipo de complejo para los mensaje de petición y repuesta para los métodos sumar y restar. Recuerde que el objetivo último es que los desarrolladores no tengan que investigar en las definiciones del esquema intentando descifrar cómo 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. Además de la información que proporciona el esquema, ¿Qué más necesita conocer el cliente para invocar los métodos 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 asociación formal entre los mensajes de petición Sumar y Restar y sus mensajes de respuesta asociados eliminarían cualquier posible ambigüedad. Una descripción formal de los patrones de mensaje resulta aún más importante en el caso de Servicio Web más complejos. Algunos servicios podrían aceptar una petición pero no enviar la respuesta correspondiente devuelta al cliente. Otros podrían solamente enviar mensajes al cliente. Además, el esquema no contiene información sobre cómo acceder al Servicio Web. Como SOAP es independiente del protocolo, se intercambiarán los mensajes entre el cliente y el servidor de numerosas formas. ¿Cómo se sabe si hay que enviar un mensaje mediante HTTP, SMTP o cualquier otro protocolo de transporte? Más aún, ¿cómo se sabe la dirección la que hay que enviar el mensaje? El lenguaje de descripción 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 información necesaria al cliente para interaccionar con el servicio Web. WSDL es extensible y se pude utilizar para describir, prácticamente, 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 están estandarizados en la comunidad del Web, cada día aumenta la posibilidad e importancia de describir las comunicaciones de forma estructurada. WSDL afronta esta necesidad definiendo una gramática XML que describe los servicios de red como colecciones de puntos finales de comunicación capaces de intercambiar mensajes. Las definiciones de servicio de WSDL proporcionan documentación para sistemas distribuidos y sirven como fórmula para automatizar los detalles que toman parte en la comunicación entre aplicaciones. Los documentos WSDL definen los servicios como colecciones de puntos finales de red o puertos. En WSDL, la definición abstracta de puntos finales y de mensajes se separa de la instalación concreta de red o de los enlaces del formato de datos. Esto permite la reutilización de definiciones abstractas: mensajes, que son descripciones abstractas de los datos que se están 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 asociación de una dirección de red y un enlace reutilizable; una colección de puertos define un servicio. Por esta razón, un documento WSDL utiliza los siguientes elementos en la definición de servicios de red:

Types: contenedor de definiciones del tipo de datos que utiliza algún sistema de tipos (por


ejemplo XSD). Message: definición abstracta y escrita de los datos que se están comunicando. Operation: descripción abstracta de una acción admitida por el servicio. Port Type: conjunto abstracto de operaciones admitidas por uno o más puntos finales. Binding: especificación del protocolo y del formato de datos para un tipo de puerto determinado. Port: punto final único que se define como la combinación de un enlace y una dirección dered. Service: colección de puntos finales relacionados.

A continuación se detalla un poco más en profundidad cada uno de estos elementos Elemento types El elemento Types contiene información 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 extensión. Si desea, utilizar otro sistema de tipo pude aparecer un elemento de extensibilidad bajo el elemento Types. El nombre de este elemento debería identificar el sistema de tipos utilizados. En este capítulo 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 abstracción común para el paso de mensajes entre el cliente y el servidor. Como puede utilizar múltiples formatos de de definición de esquema en documento WSDL es necesario de disponer de un mecanismo común de identificar los mensajes. El elemento Message proporciona este nivel común de abstracción al que se hará referencia en otras partes del documento WSDL. Pude Aparecer, y normalmente aparecerán, múltiples elementos Message en un documento WSDL, uno para cada mensaje que se comunica entre el cliente y el servidor. Cada mensaje contiene uno o más 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 parámetro que forma parte de una cadena de petición, un parámetro 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 definición de internas en donde cada método se pude definir como una operación. Un tipo puerto se compone de un conjunto de electos operation que define una determinada acción. Los electos operation se componen de mensajes definidos en el documento WSDL. WSDL define cuatro tipos de operaciones denominadas tipo operaciones:

Request-response(petición-respuesta) comunicación del tipo RPC en la que le cliente realiza una petición y el servidor envía la correspondiente respuesta. One-way (un-sentido) Comunicación del estilo documento en la que el cliente envía ubn mensaje pero no recibe una respuesta del servidor indicando el resultado del mensaje procesado. Solicit-response(solicitud-respuesta) La contraria a la operación petición-respuesta. El servidor envía una petición y el cliente le envía de vuelta una respuesta. Notification (Notificación) La contraria a la operación un-sentido el servidor envía una comunicación del estilo documento al cliente.


Elemento binding El elemento binding contiene las definiciones de la asociación de un protocolo como SOAP a un determinado bindingType. Las definiciones binding especifican detalles de formatos del mensaje y el protocolo. Por ejemplo, la información de asociación especifica si se puede acceder a una instancia de un portType de forma RPC. Las definiciones binding también indican el número de comunicaciones de re red que se requieren para realizar una determinada acción. Por ejemplo, una llamada RPC de SOAP sobre HTTP podría involucrar un intercambio de comunicación HTTP, pero esa misma llamada sobre SMTP podría involucrar dos intercambios de comunicaciones de SMTP discretas. La asociación de logra utilizando elementos de extensión. Cada protocolo tiene su propio conjunto de elementos de extensión para especificar los detalles del protocolo y el formato de los mensajes. Para un determinado protocolo los elementos de extensión se suelen utilizar para decorar las acciones individuales de una operación y la propia operación con la información de asociación del protocolo. A veces los elementos de extensión 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 dirección ú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 tecnologías. 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 definición 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 definición de elementos una asociación que haga referencia a ese conjunto concreto de electos de extensibilidad tiene que incluir dicho elemento. Lo más habitual es que los elementos de extensibilidad se utilicen para especificar especificación de asociación. La especificación WSDL define conjunto de elementos de extensibilidad para la asociación SOAP, HTTP GET, HTTP POS, MIME. Sin embargo, la especificación sólo define las asociaciones para dos de los cuatro tipos de operaciones. Un sentido y petición repuesta.

UDDI (Universal Description Discovery and Integration) Hasta ahora, se ha explicado cómo crear un servicio Web en una situación real, describiendo desde los documentos de diseño iniciales hasta las repercusiones empresariales o la implementación final. Lógicamente, el siguiente paso consiste en definir cómo se dará a conocerel servicio Web para que los clientes interesados puedan descubrirlo fácilmente 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 tecnologías y plataformas. En primer lugar, analizaré las repercusiones de UDDI, desde un punto de vista tanto tecnológico


como empresarial. A continuación, explicaré la relación entre UDDI y WDSL (Lenguaje de descripción 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 público diseñado para almacenar de forma estructurada información sobre empresas y los servicios que éstas ofrecen. A través de UDDI, se puede publicar y descubrir información de una empresa y de sus servicios. Se puede utilizar sistemas taxonómicos estándar para clasificar estos datos y poder encontrarlos posteriormente en función de la categorización. Lo más importante es que UDDI contiene información sobre las interfaces técnicas de los servicios de una empresa. A través de un conjunto de llamadas a API XML basadas en SOAP, se puede interactuar con UDDI tanto en tiempo de diseño como de ejecución para descubrir datos técnicos de los servicios que permitan invocarlos y utilizarlos. De este modo, UDDI sirve como infraestructura para una colección de software basado en servicios Web.

¿Por qué UDDI? ¿Por qué resulta necesario un registro de este tipo? Teniendo en cuenta que existe una colección de software de miles (quizás millones) de servicios Web, se nos plantean varias cuestiones difíciles: ¿Cómo se descubren los servicios Web? ¿Cómo se categoriza la información de forma coherente? ¿Cómo repercute esto en la localización? ¿Cómo afecta a las tecnologías de propietario? ¿Cómo se puede garantizar la interoperabilidad del mecanismo de descubrimiento? ¿Cómo se puede interactuar en tiempo de ejecución con este mecanismo de descubrimiento cuando mi aplicación 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 más (para obtener un listado completo, consulte UDDI: Community [en inglés]), unieron sus esfuerzos para desarrollar una especificación basada en estándares abiertos y tecnologías no propietarias que permitiera resolver los retos anteriores. El resultado, cuya versión beta se lanzó en diciembre de 2000 y estaba en producción en mayo de 2001, fue un registro empresarial global alojado por varios nodos de operadores en el que los usuarios podían realizar búsquedas y publicaciones sin coste alguno. A partir de la creación de esta infraestructura para servicios Web, los datos sobre estos servicios se pueden encontrar de forma sistemática y confiable en una capacidad universal totalmente independiente de proveedores. Se pueden llevar a cabo búsquedas categóricas precisas utilizando sistemas de identificación y taxonómicos extensibles. La integración de UDDIen tiempo de ejecución se puede incorporar a las aplicaciones. Como resultado, se fomenta el desarrollo de un entorno de software de servicios Web. ¿Cómo funciona UDDI? La información de UDDI se aloja en nodos de operador, empresas que se han comprometido a ejecutar un nodo público conforme a la especificación que rige el consorcio UDDI.org. En la actualidad existen dos nodos públicos que se ajustan a la versión 1 de la especificación UDDI: Microsoft aloja uno e IBM el otro. Hewlett Packard se ha comprometido a alojar un nodo bajo la versión 2 de la especificación. Los operadores del host deben replicar datos entre ellos a través de un canal seguro, para conseguir la redundancia de la información en el registro UDDI. Se pueden publicar los datos en un nodo y descubrirlos en otro tras la réplica. Actualmente, la réplica se produce cada 24 horas. En el futuro, este intervalo entre réplicas se reducirá, ya que habrá más 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 sólo se debe ajustar a la especificación UDDI. El nodo de Microsoft (http://uddi.microsoft.com/default.aspx [en inglés]), por ejemplo, se ha


escrito por completo en C# y se ejecuta en producción en tiempo de ejecución en lenguaje común .NET Beta 2. El código de base se beneficia claramente de la compatibilidad nativa con SOAP y de la serialización que ofrecen las clases de sistema .NET. En el lado del servidor, el nodo del operador Microsoft utiliza Microsoft® SQL Server 2000 como almacén de datos. Creo que basta con mencionar que IBM utiliza tecnologías 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 público UDDI constituye un claro ejemplo de que el modelo de servicios Web XML funciona en entornos heterogéneos. El próximo paso para comprender la iniciativa UDDI consiste en ver qué datos se almacenan en UDDI y cómo se estructuran. UDDI es relativamente ligero; se ha diseñado como registro, no como depósito. La diferencia, aunque sutil, resulta esencial. Un registro redirige al usuario a recursos, mientras que un depósito sólo almacena información. El registro Microsoft® Windows® puede servir de ejemplo: contiene las configuraciones y parámetros básicos pero, enúltima instancia, su función es la de dirigir la aplicación a un recurso o binario. Buscar un componente COM basándonos en su Id. de programa nos conducirá a un Id. de clase, que a su vez nos dirigirá a la ubicación 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 búsquedas y determinar la ubicación de recursos. En última instancia, las consultas a UDDI conducen a una interfaz (un archivo .WSDL, .XSD, .DTD, etc.) o a una implementación (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 implementación basada en una de estas interfaces?" "¿Qué servicios Web, categorizados de algún modo, se ofrecen actualmente?" "¿Qué servicios Web ofrece una empresa determinada?" "¿Con quién se debe poner en contacto el usuario para utilizar los servicios Web de una empresa?" "¿Cuáles son los detalles de implementación 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 cómo colaboran UDDI y WSDL y por qué la idea de interfaces frente implementaciones forma parte de cada protocolo. WSDL y UDDI se diseñaron para diferenciar claramente los metadatos abstractos y las implementaciones concretas. Para entender cómo funcionan WSDL y UDDI resulta esencial comprender las consecuencias de esta división. Por ejemplo, WSDL distingue claramente los mensajes de los puertos: los mensajes (la sintaxis y semántica 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 información sobre el puerto. Un archivo WSDL puede contener simplemente información abstracta de interfaz, sin facilitar datos de implementación concretos, y ser válido. De este modo, los archivos WSDL se separan de las implementaciones. Una de las consecuencias más interesantes de esto es que pueden existir varias implementaciones de una única interfaz WSDL. Este diseño permite que sistemas dispares escriban implementaciones de la misma interfaz, para garantizar así la comunicación entre ellos. Si tres empresas diferentes implementan el mismo archivo WSDL y una parte del softwarede cliente crea el código auxiliar/proxy a partir de esa interfaz, dicho software se podrá comunicar con las tres implementaciones con el mismo código de base, cambiando simplementeel punto de acceso. UDDI establece una distinción similar entre la abstracción y la implementación con el concepto de tModels. La estructura tModel, abreviatura de "Technology Model" (modelo de tecnología),


representa huellas digitales técnicas, interfaces y tipos abstractos de metadatos. El resultado delos tModels son las plantillas de enlace, que son la implementación concreta de uno o más tModels. Dentro de una plantilla de enlace se registra el punto de acceso de una implementación particular de un tModel. Del mismo modo que el esquema de WSDL permite separar la interfaz y la implementación, 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 estándares publica la interfaz canónica para un sector particular y, a continuación, varias empresas escriben implementaciones de esta interfaz. Obviamente, cada una de estas implementaciones haría referencia al mismo tModel. Los archivos WSDL constituyen un ejemplo perfecto de tModel de UDDI.

Registro en UDDI La publicación en UDDI es un proceso relativamente sencillo. El primer paso consiste en determinar información básica sobre cómo definir la empresa y los servicios en UDDI. El siguiente paso, una vez determinada esta información, consiste en llevar a cabo el registro, ya sea mediante programación o a través 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 búsquedas y herramientas. Primer paso: Definir la entrada de UDDI Partiendo del modelo de datos descrito anteriormente, se debe recopilar cierta información 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 diseño 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 identificadorGUID 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 debería tener un formato URI (identificador de recursos uniforme), como MyCompany-com:SampleWebService-interface:v1, y señalar a la ubicación del archivo WSDL. Si su servicio Web es un servicio de Microsoft® Visual Studio® .NET, podrá generar una descripción 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 invocación del servicio Web, lo cual puede no resultar adecuado cuando la interfaz del servicio tiene varias implementaciones. Esto no supondrá ningún problema si su intención es que el archivo WSDL sólo tenga una implementación. Determine el nombre de la empresa y una breve descripción 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 descripción en varios idiomas. Asimismo, UDDI permite enumerar los contactos, incluyendo datos como el correo electrónico, el teléfono y la dirección. Esta lista de contactos muestra los recursos de una empresa con los que se puede poner en contacto en relación 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, ¿cómo puede llegar a saber quién es? ¿Existe algún contacto para obtener asistencia técnica a la hora de utilizar los servicios Web de la empresa? También se debería incluir en la lista a esta persona. Determine las categorías e identificaciones adecuadas para la empresa. Podrá explorar los sistemas taxonómicos compatibles con UDDI actualmente en el nodo


Microsoft UDDI (http://uddi.microsoft.com/default.aspx [en inglés]). 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 categorías que representan de forma más acertada a su empresa. Determine los servicios Web que la empresa ofrece a través de UDDI. A continuación, deberá determinar los servicios Web que desea registrar la empresa en el nodo público UDDI. ¿Existen varios puntos de acceso para este servicio? ¿Es preciso que los clientes conozcan otros parámetros y otra información 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 acompañar medidas de seguridad, autorización y autenticación. No basta que el usuario sepa que existe un servicio Web para que pueda invocarlo. Puede existir una comunicación fuera de banda entre empresas antes de permitir el acceso a un servicio Web. Determine las categorías 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 debería 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 definición, el siguiente paso consiste en registrar la empresa. Deberá obtener una cuenta con un registro UDDI. Esta operación no se puede realizar mediante programación, ya que deberá mostrar su conformidad con una declaración de condiciones de uso. El nodo de Microsoft utiliza Passport para la autenticación, 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 programación 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 más compleja, resulta recomendable realizar el proceso de registro con secuencias de comandos, utilizando el SDK de Microsoft UDDI. Además, la interfaz de usuario de Microsoft no está localizada en otros idiomas, así que se deberá registrar mediante programación para disfrutar esa característica 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 asegúrese de que aparece en el cuadro de diálogo "Agregar referencia Web". Si no aparece, se puede deber a que el tModel no se categorizó correctamente utilizando la taxonomía uddi-org:types descrita anteriormente. Podrá agregar el servicio Web al proyecto y generar el código 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 inglés). Para Terminar UDDI y WSDL funcionan como especificaciones gratuitas que facilitar el desarrollo de una colección 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 próxima generación, mientras que UDDI proporciona una amplia


infraestructura estandarizada que permite al usuario describir y descubrir servicios Web. Mediante la combinación de estos dos estándares, se podrá desarrollar todo un universo de servicios Web.

¿Son seguros los Servicios Web XML? Teniendo en cuenta todos los aspectos de seguridad, autenticación y autorización, confidencialidad e integridad de datos, etc., y el hecho de que la especificación SOAP ni siquiera menciona la seguridad, es fácil llegar a la conclusión de que la respuesta es negativa. Pero no hay que subestimar los servicios Web XML de Microsoft®. Hoy en día, 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:

¿Cuál 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. ¿Cómo vamos a cumplir con el objetivo deseado? Red, capa de transporte, sistema operativo, servicio o aplicación. ¿Qué nivel de interoperabilidad deseamos y necesitamos en nuestra solución? Local o global. ¿Cómo se puede aumentar la seguridad de los servicios Web XML actuales?

Esto se consigue respondiendo a las preguntas anteriores y, a continuación, aplicando las mismas técnicas de seguridad que utilizaríamos para cualquier otra aplicación Web:

Crear conexiones seguras Autenticar y autorizar la interacción

Como podrá comprobar seguidamente, estas técnicas 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 (métodos) basándose 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. Creación de una infraestructura segura una infraestructura segura es la clave para contar con servicios Web XML seguros. Microsoft ofrece una amplia gama de tecnologías que, una vez integradas en un plan general de seguridad, permiten a las empresas proteger eficazmente una infraestructura informática. Para completar la implementación con éxito, la planeación debe considerar lo siguiente:

Tener una idea detallada de los riesgos potenciales del entorno (como virus, intrusos y desastres naturales. Realizar un análisis activo de la relación entre las consecuencias y contramedidas de una intrusión y los riesgos. Crear una estrategia de implementación planeada con detenimiento para integrar las medidas de seguridad en el conjunto de una red empresarial, basándose en los dos puntos anteriores.

Creación de conexiones seguras Uno de los métodos más sencillos para aumentar la seguridad de los servicios Web XML consiste en asegurarse de que la conexión entre el cliente de servicios Web XML y el servidor es segura. Esto se puede llevar a cabo mediante varias técnicas, dependiendo de la extensión de la red y el perfil de actividades de las interacciones. Tres de las técnicas más 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 técnica 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 proporcionen distintas restricciones para clientes diferentes según su origen o identidad. Esto resulta de gran utilidad cuando se espera que determinados clientes tengan acceso a funcionalidades (métodos) 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 leídos por terceros durante la transmisión. SSL cifra el mensaje del cliente y, a continuación, lo envía al servidor. Una vez que el servidor lo recibe, SSL lo descifra y comprueba que procede del remitente correcto (proceso que se denomina autenticación. El servidor, o el servidor y el cliente, pueden tener certificados que se utilizan como parte del proceso de autenticación y que proporcionan capacidades de autenticación además del cifrado de la conexión. Aunque es un método 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 extensión de una red privada que se conecta a través de redes compartidas o públicas, como Internet. Las redes virtuales privadas permiten enviar datos entredos equipos en una conexión segura. Si bien su funcionamiento es similar a SSL, una red virtualsegura es una conexión punto a punto establecida a largo plazo. De este modo, mejora la eficacia y permite la comunicación con servicios Web XML, pero requiere que se establezca una conexión duradera a largo plazo para obtener un rendimiento mayor.

Seguridad en servicios web. Autenticación y autorización. Interoperabilidad 2 Autenticación y autorización 2.1 Autenticación: La autenticación 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 autenticación requiere pruebas de identidad, denominadas credenciales. Por ejemplo, una aplicación cliente puede presentar una contraseña como sus credenciales. Si la aplicación cliente presenta las credenciales correctas, se asume que es quien dice ser. 2.2 Autorización: Una vez que se ha autenticado la identidad de un principal, deben tomarse decisiones sobre la autorización. El acceso se determina comparando la información del principal con información 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 estarían autorizados sólo a ciertas operaciones. A algunos clientes se les permitirá un acceso total a todos los datos, mientras que a otros sólo se les permitirá acceso a un subconjunto de los datos y otros tendrán acceso de sólo lectura. Un modo sencillo de implementar servicios Web XML Web consiste en aprovechar las características de autenticación del protocolo que se utilice para intercambiar mensajes. Para la mayoría de los servicios Web XML, esto significa aprovechar las características de autenticación disponibles en HTTP. Microsoft Internet Información Server (IIS) e ISA Server funcionan en


conjunción con Windows 2000 Server y ofrecen soporte para varios mecanismos de autenticación en HTTP.

Básica: utilizada para identificación no segura o poco segura de clientes, ya que el nombre de usuario y la contraseña se envían como texto codificado en base 64, que puede ser fácilmente descodificado. IIS autorizará el acceso a los servicios Web XML si las credenciales coinciden con las de una cuenta de usuario válida. Básica sobre SSL: igual que la autenticación básica, excepto que el canal de comunicación está cifrado y protege de ese modo el nombre de usuario y la contraseña. Una buena opción para entornos en Internet; sin embargo, el uso de SSL influye negativamente en el rendimiento. Implícita: 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 válida. Autenticación de Windows integrada: resulta útil sobre todo en entornos en Intranet. Utiliza NTLM o Kerberos. El cliente debe pertenecer al mismo dominio que el servidor o a un dominio en el que el dominio del servidor confía. IIS autorizará el acceso a los servicios Web XML si las credenciales coinciden con las de una cuenta de usuario válida. Certificados de cliente a través de SSL: requiere que cada cliente obtenga un certificado. Los certificados se asignan a las cuentas de usuario, que son utilizadas por IISpara autorizar el acceso a los servicios Web XML. Se trata de una solución 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. Sólo 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 autenticación es que no se necesita escribir nuevo código. IIS/ISA Server completa todo el proceso de autenticación y autorización ACL antes de llamar a los servicios Web XML. Sin embargo, al implementar el cliente será necesario realizar algunas tareas adicionales. La aplicación cliente necesitará responder a las peticiones de autenticación y credenciales del servidor. Entre los métodos para la implementación de autenticación en servicios Web XML también se incluyen servicios de terceros, como los que se encuentran en Microsoft® . NET Passport, características de sesión de Microsoft ASP.NET o la creación de métodos de autenticación personalizados. 3 Próximamente: Interoperabilidad Como puede ver, las técnicas habituales para crear aplicaciones Web seguras se pueden aplicar por separado o combinadas a la hora de proteger servicios Web XML. Estas técnicas ya se han utilizado en el pasado y resultan bastante efectivas. Sin embargo, no ofrecen una solución integrada dentro de la arquitectura de servicios Web XML. Conforme aumenta la complejidad del entorno de servicios Web XML (sobrepasando los límites de la confianza, extendiéndose a múltiples 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 están trabajando en un conjunto de especificaciones de seguridad basadas en el mecanismo de extensibilidad de la especificación SOAP para ofrecer funciones de seguridad mejoradas e integradas en el núcleo mismo de los servicios Web XML. Una de las principales especificaciones que se están desarrollando es el lenguaje de seguridad de servicios Web XML (WS-Security) que proporciona mejoras en la mensajería SOAP, consistentes en tres funcionalidades: transferencia de credenciales, integridad de mensajes y confidencialidad. Estas funcionalidades no proporcionan por sí mismas una solución de seguridad completa; WS-Security es una pieza que se puede utilizar en conjunción con la


infraestructura y otros protocolos de servicios Web XML para hacer frente a un gran número 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 evolución 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 años, 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 clásica, se está desarrollando e implantando tecnologías de servicios Web en paralelo, progresando a través de un ciclo de realimentación positivo. Aunque los servicios Web han progresado mucho en los últimos tres años, el trabajo sobre la plataformacontinúa. Si vamos a desarrollar sistemas basados en servicios Web, es importante comprender dónde 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 más cosas (por ejemplo, enviar mensajes SOAP sobre SMTP. Sin embargo, la mensajería basada en HTTP es la única opción de comunicación más generalmente soportada. La mayoría de las herramientas de Servicios Web mapea mensajes SOAP a invocaciones de métodos en objetos. Algunas proporcionan además un acceso directo al cuerpo de los mensajes SOAP, exponiéndolos como XML. Servicios de alto nivel como la seguridad se implementan generalmente de modo ad hoc, típicamente en el nivel de los protocolos de transporte. La mayoría 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 reuniéndose periódicamente para garantizar que sus kits de herramientas trabajan conjuntamente. Muchos de los trabajos de la comunidad SOAPBuilders han sido necesarios en relación 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 debería aportar mejoras sustanciales. El grupo XML Protocol Working Group está trabajando en la especificación SOAP 1.2 mientras que el grupo Web Services Description Working Group está creando la especificación WSDL 1.2. Mientras tanto, IETF y OASIS están también 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 núcleo de los servicios Web, existe otra organización independiente que está prestando más atención a la interoperabilidad. La organización Web Services Interoperability Organization (WS-I) tiene como objetivo definir mejores prácticas para garantizar la interoperabilidad de los servicios Web. El grupo WS-I Basic Profile Working Group está actualmente desarrollando un conjunto de recomendaciones sobre cómo utilizar los protocolos básicos 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 aparecerán mejoras en tres áreas fundamentales. En primer lugar, se añadirán servicios de más alto nivel. Todo el mundo está de acuerdo en que debe existir un modo estándar de asegurar servicios Web, rutear mensajes, garantizar una entrega fiable de mensajes, definir semántica transaccional, etc. Estas características de propósito general se expanden más allá de los dominios del


problema y no hay ninguna razón por la que cada desarrollador de servicios Web deba implementarlas individualmente. Microsoft, IBM y otros están realizando mucho trabajo en estas áreas. La iniciativa Global XML Web Service Architecture (GXA) define un conjunto de especificaciones sobre cómo implementar estos servicios de infraestructura en términos de mensajes SOAP (por ejemplo, de un modo neutral respecto del protocolo de transporte. En segundo lugar, seguirán estandarizándose especificaciones. El ciclo de vida de las especificaciones de servicios Web típicamente progresa desde una propuesta hasta un estándar de facto y desde éste hasta un estándar real. Con SOAP 1.2 y WSDL 1.2 las peculiaridades finales están siendo elaboradas de las especificaciones SOAP y WSDL y algunas de las especificaciones de servicios de mayor nivel, como WS-Security, ya están en el periodo "de facto" en el proceso de estandarización. Las empresas siguen proponiendo nuevas especificaciones como añadidos a la plataforma de servicios Web y la industria en su conjunto necesitará acordar cuáles adoptar. Esas especificaciones necesitarán a continuación ser estandarizadas. En tercer lugar, los kits de herramientas y marcos de trabajo seguirán mejorando. Además de servicios de más alto nivel como la seguridad y los objetos adjuntos, se añadirá soporte para protocolos de transporte alternativos como SMTP o TCP. De modo más importante, los modelos de programación migrarán desde los servicios de tipo RPC hacia servicios centrados en documentos, para promover un acoplamiento débil. Todos estos cambios ocurrirán en paralelo, mientras los desarrolladores continúan desarrollando e implantando sistemas basados en servicios Web. 3 Avances de futuro Llegados a este punto, estaremos preguntándonos cómo podemos utilizar los servicios Web cuando la plataforma todavía está evolucionando. Las herramientas y marcos de trabajo de los servicios Web actuales proporcionan suficiente funcionalidad básica para desarrollar interesantes aplicaciones distribuidas que envían mensajes SOAP sobre HTTP. Algunos servicios de mayor nivel como WS-Security están empezando a cuajar con el soporte de diversas herramientas nuevas como el kit Web Services Development Kit. Otros servicios están todavía 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 demás características. Si queremos desarrollar servicios Web utilizando herramientas de Microsoft, tenemos varias opciones. Si todavía estamos utilizando Visual Studio 6.0 o algún otro entorno de desarrollo que no soporta el desarrollo de código gestionado, podemos crear y consumir servicios Web utilizando el kit de herramientas SOAP Toolkit. Si estamos utilizando .NET, podemos focalizarnos en los métodos Web de ASP.NET (a esto hace referencia la mayor parte de la documentación de .NET sobre los servicios Web). En cualquier caso, podemos aprender tanto como queramos sobre cómo funcionan los protocolos de mensajería y metadatos de los servicios Web. Cuanto más comprendamos la fontanería, más fácil será desarrollar nuestros propios servicios y utilizar servicios desarrollados por los demás. También podemos experimentar con las nuevas especificaciones. La versión preliminar del kit Microsoft WSDK Technology Preview proporciona un soporte preliminar para las especificacionesWS-Security, WS-Routing y DIME. Podemos también 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 opción no es para todo el mundo, pero si tenemos tiempo y recursos, obtendremos pronto una avanzada funcionalidad. Además, contribuiremos al desarrollo de la plataforma. El entendimiento colectivo de SOAP Y WSDL se mejoró sustancialmente gracias al intento de implementación de sistemas basados en ambos estándares por parte de múltiples usuarios. Cuanto más estrechamente trabajen los usuarios con las nuevas especificaciones, mejor resultará la plataforma de servicios Web global.


Introducción al entorno de desarrollo de Microsoft .NET 1 El nuevo modelo de computación distribuida en Internet. Nos encontramos en un momento especial en la industria de computación. Estamos en el inicio de una nueva manera de hacer y de integrar las aplicaciones. Algunos gurús de la industria de computación vaticinan que este cambio ser equivalente al que produjo la introducción de la PC, la interfase visual o al surgimiento mismo de Internet. Dispositivos móviles como celulares, TabletPC (PCs que parecen un cuaderno de notas pero tienen la capacidad de una computadora de escritorio), hasta televisores u otros dispositivos hogareños estarán conectados entre sí, con servidores y distintas aplicaciones. El elemento integrador será Internet. Estamos ahora en el inicio de la tercera generación de Internet. Con Visual Studio .NET y ASP.NET Web Matrix vamos a ser protagonistas del cambio. El tema de fondo es romper barreras. Barreras entre distintas aplicaciones que tienen información, barreras entre sistemas, barreras entre los sistemas y la gente que los utiliza, barreras entre las organizaciones. ¿Cómo se llega a este nuevo modelo de computación? La década de los 80's fue marcada por el surgimiento de la PC y de la interfase grafica. En la década de los 90's Internet permitió conectar computadoras en una escala global. En principio la conexión fue entre PCs y servidores por medio del explorador de Internet. A comienzos de este siglo es clara la necesidad de permitir a las computadoras conectadas a Internet comunicarse entre ellas. Desde entonces se va dando forma al nuevo modelo de computación distribuida llamado servicios Web basados en XML. El objetivo es permitir comunicarse entre sí a sistemas heterogéneos dentro y fuera de la empresa. Esta comunicación es independiente del sistema operativo, lenguaje o modelo de programación. Para conseguir esto se desarrollaron estándares. El consorcio de Internet http://www.w3c.org fue el encargado de crear y mantener estos estándares. Estos son algunos de los estándares que permiten hacer uso de los Servicios Web basados en XML:

XML: (Lenguaje de Marcado eXtensible) Es un formato universal para representar los datos. SOAP: (Protocolo Simple de Acceso a Objetos) Es un protocolo que permite mover los datos entre aplicaciones y sistemas. Es el mecanismo por medio del cual los servicios Webson invocados e interactúan. UDDI: (Descubrimiento, Descripción e Integración Universal) Lenguaje que permite publicar, encontrar y usar los Servicios Web basados en XML. Es la 'Página Amarilla' de los servicios Web es decir un directorio para poder encontrarlos. Puede ser accedido con un explorador en http://www.uddi.org o programáticamente ya que UDDI es también un servicio Web. WSDL: (Lenguaje de Descripción de Servicios Web) Lenguaje por medio del cual un servicio Web describe entre otras cosas qué hace o qué funcionalidad implementa. La competencia en la industria de software no pasa por imponer el protocolo sobre el cual se va a construir la nueva generación de Internet, debido a que están ya establecidos (aunque en continuo desarrollo).

Nadie discute tampoco la importancia del uso de los servicios Web, toda la industria de softwareesta enfocada a ello. La competencia es por proveer de las mejores herramientas basadas en estándares y las más fáciles y más productivas herramientas para construir las aplicaciones. La plataforma .NET es la infraestructura, los servicios y productos que Microsoft ofrece.


Antes de la adopción del modelo de Servicios Web basados en XML los datos eran 'islas' que se encontraban dentro de las aplicaciones en las empresas. Era muy difícil y costoso implementar soluciones para acceder a la información desde afuera de la aplicación y la empresa. Las aplicaciones pueden ahora, comunicarse entre sí y con los sistemas de sus socios, proveedores y clientes gracias a los Servicios Web y XML. En resumen, con el uso de los servicios Web se integra la información que puede ser accedida desde distintos dispositivos, desde distintas plataformas de hardware o software y que puede estar guardada en distintos formatos. El lenguaje estándar para lograr esta integración es XML. Todos los servidores corporativos de .NET entienden este lenguaje. Siguientes versiones de estos servidores van a incorporar muchas mejoras en este aspecto. Ejemplo de esto es la siguiente versión de SQL Server 2000 llamada Yukon. Este producto puede guardar datos en formato nativo XML, además permite hacer consultas al servidor no solamente en el lenguaje típico de bases de datos sino también en cualquier lenguaje compatible con la plataforma .NET. 2 ¿Qué es la plataforma .NET? Provee los cimientos para la nueva generación de software. Utiliza los Servicios Web como un medio para poder interoperar a distintas tecnologías. Permite conectar distintos sistemas operativos, dispositivos físicos, información y usuarios. Les da a los desarrolladores las herramientas y tecnologías para hacer rápidamente soluciones de negocios que involucran distintas aplicaciones, dispositivos físicos y organizaciones.

FIGURA IX.1: "Esquema general de la Plataforma .NET" La idea central detrás de la plataforma .NET es la de servicio. Más concretamente software como servicio y de cómo construir, instalar, consumir, integrar o agregar (en federaciones) estos servicios para que puedan ser accedidos mediante Internet. Esto es posible debido a que tenemos la infraestructura de comunicación global que es Internet cada vez más rápida y a un costo cada vez menor y además, a la capacidad de los procesadores que continúa incrementándose año tras año. El usuario de Internet puede con un explorador de Internet no solamente acceder a contenido como texto, imágenes o sonido, también puede hacer uso de servicios Web. Estos son los bloques de construcción o componentes sobre los cuales se basa el modelo de computación distribuida en Internet. La plataforma .NET permite usar Internet y su capacidad de distribución para que los usuarios accedan desde cualquier dispositivo, en cualquier sistema operativo y lugar a la funcionalidad que los servicios Web proveen. Los desarrolladores por su parte tienen la infraestructura y herramientas para crearlos y hacer uso de ellos en programas. Es decir, se trata de aprovechar la capacidad de distribución a gran escala de Internet para acceder a servicios de software. También se trata de aprovechar el incremento en la capacidad de procesamiento de los nuevos dispositivos móviles llamados "Smart Devices" (dispositivos inteligentes) para que el usuario haga uso de la funcionalidad que proveen los servicios Web con interfases cada vez más sencillas y naturales como la voz o la escritura. La siguiente versión del portal MSN, MSN 8, es un ejemplo de software como servicio. Utiliza losladrillos de construcción que proveen el servicio Web Passport y .NET Alerts (los cuales estudiaremos más adelante). Permite además instalar software actualizado mientras se hacen


otras cosas. La actualización de software es un servicio al que hay que subscribirse independientemente de la plataforma desde la cual se accede. El nuevo modelo de computación basado en Internet implica que la empresas no solamente tengan sitios donde el contenido puede ser accedido de manera visual como hasta ahora, con un explorador de Internet. Si quieren ser exitosas deben crear componentes que implementen servicios relacionados con su actividad para que usuarios o sitios los integren y utilicen. Por ejemplo, una aerolínea puede hacer componentes para la reserva de pasajes y desde una aplicación de una empresa de turismo llamar a este componente. O un usuario desde un dispositivo móvil (por ejemplo un celular) puede también invocar el componente de reserva de pasajes aéreos directamente para ver la disponibilidad y hacer reservaciones. La empresa turística puede exponer un servicio Web que incluya la llamada al servicio Web de la aerolínea. Cuando un servicio Web llama a otros se crea lo que se llama federación de servicios Web y las posibilidades funcionales se multiplican.

Componentes de la plataforma .NET. La plataforma .NET no es un solo producto. Es un conjunto de productos. Desde sistemas operativos como Windows XP, servidores de aplicaciones como SQL Server 2000, productos de oficina como Office XP, herramientas de desarrollo como Visual Studio .NET hasta servicios Web provistos por Microsoft como .NET Passport. Tanto la invocación de los servicios como su ejecución pueden ser hechas en cualquier dispositivo y sistema operativo, y accedido desde Internet. Los sitios se comunican entre sí y acceden a servicios y contenidos sin la intervención humana. Por eso se llama a la nueva generación de Internet "Internet inteligente". Los componentes de la plataforma .NET son: Smart Clients (Clientes Inteligentes): Son dispositivos muy variados. Lo que los hace 'Smart' ointeligentes es su capacidad para hacer uso de servicios Web. Sus características son:

Permiten acceder a la información en el formato apropiado, en cualquier momento y lugar. Hacen uso de Servicios Web. Optimizan de distintas maneras la forma en que la información es presentada y organizada. Por ejemplo: Pueden convertir texto en sonido en un celular o reconocer la escritura en un TabletPC. Proveen de una interfase sencilla y natural para que el usuario acceda a la información. Pueden utilizar la identidad del usuario, su perfil y datos para adaptar la información que es presentada. Pueden reconocer la presencia de otros dispositivos e intercambiar información. Pueden adaptarse a las características de la red donde están. Por ejemplo la velocidad de transmisión. Tienen capacidad de procesamiento propio, y distribuyen el procesamiento en la red haciendo uso de los servicios Web.

Ejemplo de estos son:

PocketPC (PC de bolsillo) SmartPhone (Teléfono Inteligente) HandHelds TabletPC XBox (Consola de juegos de Microsoft)


PCs: Las computadoras personales. NoteBooks: Las computadoras portátiles. Y muchos otros dispositivos en desarrollo. Además: Servidores: Proveen de la infraestructura para implementar el modelo de computación distribuida en Internet. Son sistemas operativos y de aplicación. Sistemas Operativos: Windows 2000: Server, Advance Server y Datacenter, Windows Server 2003: Standard, Enterprise, Datacenter y Web Server. Servidores .NET Corporativos:

Microsoft Application Center 2000: Para instalar y administrar aplicaciones Web altamente disponibles y escalables. Microsoft BizTalk Server 2000 : Para construir procesos de negocios basados en XML a través de distintas aplicaciones y organizaciones. Microsoft Commerce Server 2000: Para construir rápidamente soluciones de e-commerce escalables. Microsoft Content Management Server 2001: Para administrar contenido para sitios Web de e-bussines dinámicos. Microsoft Exchange Server 2000: Para permitir enviar mensajes y trabajar en forma colaborativa en cualquier momento y lugar. Microsoft Host Integration Server 2000: Para acceder a datos y aplicaciones en mainframes. Microsoft SQL Server 2000: Para almacenar, recuperar y analizar datos en formato XML. Microsoft SharePoint Portal Server 2001: Para encontrar, compartir y publicar información de negocios. Microsoft Internet Security and Acceleration Server 2000: Para conectividad a Internet rápida y segura. Microsoft Mobile Información 2001 Server: Para soportar aplicaciones en dispositivos móviles como por ejemplo celulares.

Servicios Web basados en XML: Son los bloques de construcción de la tercera generación de Internet. Algunas de sus características son:

Permiten a las aplicaciones compartir datos. Son componentes. Es decir, unidades de código discretas, cada una haciendo una tarea en particular. Están basados en el lenguaje universal de intercambio de datos de Internet: XML. Pueden ser llamados desde distintos sistemas operativos, plataformas de hardware y lenguajes de programación.

Herramientas de desarrollo: Visual Studio .NET y el .NET Framework. Ambos permiten al desarrollador hacer servicios Web basados en XML además de otro tipo de aplicaciones. El .NET Framework viene incorporado directamente en la nueva línea de sistemas operativos Windows .NET. Para los dispositivos móviles se llama .NET Compact Framework. Los componentes de la plataforma .NET pueden interactuar de distintas maneras. Esta comunicación es permitida por los servicios Web que integran los distintos tipos de dispositivos y componentes. Analicemos 4 tipos de interacciones posibles: Cliente con Cliente: Smart Clients o dispositivos pueden proveer de servicios Web y utilizarlos para permitir que la información este disponible en todo momento y lugar. Cliente con Servidor: Los servicios Web permiten que un servidor comparta datos con una PC o un dispositivo móvil vía Internet. Servidor con Servidor: Una aplicación en un servidor puede programáticamente acceder a otra aplicación utilizando un servicio Web como interfase.


Servicio con Servicio: Un servicio Web puede invocar a otro, aumentando de esta manera la funcionalidad disponible.

La plataforma .NET Es claro entonces que el objetivo de la plataforma .NET es simplificar el desarrollo de aplicaciones Web. Provee las herramientas y tecnologías para transformar a Internet en una plataforma de computación distribuida en gran escala. Esta plataforma además soporta los estándares sobre los cuales se basan los servicios Web.

Figura IX.2: "La Plataforma .NET" La plataforma .NET utiliza tecnologías existentes, productos modificados para su uso dentro de la plataforma y elementos nuevos. Productos existentes: COM. Microsoft tiene una tecnología para la creación, invocación y uso de componentes llamada COM (Modelo de Objetos Componentes). Al igual que el protocolo SOAP utilizado para la invocación de los servicios Web, COM establece las reglas acerca de cómo los objetos deben ser invocados y cómo deben interactuar. También los componentes COM pueden implementar funcionalidad similar a la de los servicios Web. Sin embargo tienen dos puntos en contra. Primero: No son una tecnología estándar. Segundo: No pueden ser utilizados fuera de la barrera de seguridad que las empresas tienen para su comunicación hacia y desde Internet (firewall). Por lo tanto no sirven al modelo de computación distribuida en Internet. Sin embargo, hay muchas soluciones que usan COM en el mercado. La plataforma .NET puede por medio de clases especiales hacer uso de COM y los objetos COM también pueden hacer uso de servicios Web. Lo que permite aprovechar la plataforma instalada para el desarrollo de nuevos proyectos. Productos Modificados: La familia de sistemas operativos de Windows 2000 fue modificada para soportar a la plataforma .NET. También todos los productos de servidores de aplicaciones fueron modificados para permitir la interoperatividad basada en XML. Elementos Nuevos: BizTalk Server es un producto pensado para entender y manipular datos en formato XML y para poder transformar datos en XML a otros formatos y viceversa. Permite coordinar el flujo de información entre aplicaciones dentro de la empresa y también "orquesta" el flujo de datos con otras empresas. De ahí que se califique a su función como "orquestación". Algo muy importante actualmente ya que las distintas aplicaciones deben comunicarse entre sí y muchas veces los formatos de los datos son incompatibles. El .NET Framework es una tecnología nueva de Microsoft y por su importancia merece que la estudiemos con detenimiento

El .NET Framework


El .NET Framework se instala como un componente aparte en Windows 2000, mientras que Windows XP y las futuras versiones de Windows lo incorporan directamente al sistema operativo. Como por ejemplo Windows Server 2003 o Windows .NET CE. El .NET Compact Framework permite hacer uso de los servicios Web en dispositivos móviles. Debido a que es un subconjunto del .NET Framework comparte el mismo modelo de programación y herramientas de desarrollo de aplicaciones haciendo posible que los desarrolladores transfieran sus conocimientos existentes al desarrollo de aplicaciones móviles.

Figura IX.3 "El Componente del Marco de trabajo .NET " Los componentes del .NET Framework proveen los "ladrillos" necesarios para construir las aplicaciones Web, los servicios Web y cualquier otra aplicación dentro de Visual Studio .NET. Ahora que tenemos una visión general del .NET Framework, vamos a estudiar que función cumplen las partes que lo componen.

Figura IX.4: "Runtime del Leguaje Común" El Common Language Runtime provee lo que se llama código administrado, es decir, un entornoque provee servicios automáticos al código que se ejecuta. Los servicios son variados:

Cargador de Clases: Permite cargar en memoria las clases. Compilador MSIL a nativo: Transforma código intermedio de alto nivel independiente del hardware que lo ejecuta a código de máquina propio del dispositivo que lo ejecuta. Administrador de Código: Coordina toda la operación de los distintos subsistemas del Common Language Runtime. Recolector de Basura: Elimina de memoria objetos no utilizados. Motor de Seguridad: Administra la seguridad del código que se ejecuta. Motor de Depuración: Permite hacer un seguimiento de la ejecución del código aún cuando se utilicen lenguajes distintos. Verificador de Tipos: Controla que las variables de la aplicación usen el área de memoria que tienen asignado. Administrador de Excepciones: Maneja los errores que se producen durante la ejecución del código.


Soporte de multiproceso (threads): Permite ejecutar código en forma paralela. Empaquetador de COM: Coordina la comunicación con los componentes COM para que puedan ser usados por el .NET Framework. Soporte de la Biblioteca de Clases Base: Interfase con las clases base del .NET Framework.

Figura IX.5: "Librería de Clases .NET" La librera de clases base son las clases sobre las cuales se construyen todas las demás clases que utilizan los programas de Visual Studio .NET. La clase madre de todas es System. A partir de ella por un mecanismo llamado herencia de clases, se construyen las demás clases. Debido a que en la librería de clases base hay muchas clases, se utiliza para identificarlas un mecanismo llamado espacio de nombres (namespace). La parte del nombre de la clase que se encuentra a la derecha del último punto se llama tipo de la clase. Todo lo que resta se llama espacio de nombres. Por ejemplo: En la clase llamada System.Runtime.InteropServices, InteropServices es el tipo de la clase y System.Runtime es el espacio de nombre. El espacio de nombre es una manera de organizar en grupos las distintas clases. Esto hace más manejable y fácil su uso. La librera de clases base es independiente del lenguaje. Permite el uso y la depuración de otros lenguajes. Es extensible ya que por el mecanismo de herencia el usuario puede crear nuevas clases que usan las clases base como "ladrillos". También el usuario puede incorporarlas en bibliotecas para su utilización posterior. Es segura ya que es posible permitir o restringir su uso por medio de distintos mecanismos de seguridad. Cómo funciona el .NET Framework. Cuando usted crea una aplicación Windows en algún lenguaje compatible con la plataforma .NET, puede utilizar cualquiera de los servicios que la biblioteca de clases de .NET provee. Por ejemplo: Puede usar clases para hacer ventanas que tengan distintos tipos de controles. Cuando compila la aplicación, se crea un código intermedio llamado MSIL. Este código es independiente de la plataforma de hardware. Una vez compilado, el ejecutor de lenguaje común administra la ejecución de la aplicación.

Figura IX.6: "Funcionamiento del .NET Framework." Uno de los subsistemas del Common Language Runtime se llama compilación JIT, que transforma el código intermedio MSIL al código de máquina en el sistema donde la aplicación se va a ejecutar. Esta compilación a lenguaje de máquina


lo hace en el momento de ejecución del código. Cuando un dispositivo de cliente, por ejemplo, un celular "Smart phone", ejecuta una aplicación hecha con Visual Studio .NET, se ejecuta en el código de máquina del sistema del cliente. La aplicación sin embargo puede interactuar con otras aplicaciones .NET y servicios independientemente del lenguaje en que fueron desarrollados.

Desarrollo y consumo de un Web Services con Microsoft Visual Studio .Net 1 Introducción. El objetivo de la actividad es presentar fundamentos teóricos generales relativos a la tecnología de webservices, y como puede ser implementada en los escenarios más comunes con que nos encontraremos. Como implementación, comenzaremos construyendo un webservice muy sencillo, el cual será testado a través del browser. Desarrollaremos aplicaciones cliente (consumidoras) del Web Service, como:

Página ASP.Net

Aplicación Windows .Net

Aplicación Excel de Office XP

Aplicación de Internet Mobile

Aplicación Visual Basic 6.0

Requerimientos Software Servidor - Webservice

Windows 2000, XP, superior

Internet Information Service

.Net Framework (SDK)

Desarrollo Webservice

Visual Studio .Net o Notepad.

Cliente webservice (Consumidor)

MS SoapToolkit

Office XP o Webservice referente toolkit (para creación del Proxy)

2 Implementación Desarrollando un webservice 1.) En Visual Studio .Net, creamos un proyecto ASP.Net Webservices, llamado "WorkShopUDP_v1"


2.) Eliminar los comentarios (comilla simple) del método HelloWorld() de la clase - service1. 3.) Cambiamos el nombre de la "Service1" por "Saludo" Antes: Imports System.Web.Services <WebService(Namespace := "http://tempuri.org/")> _ Public Class Service1 Inherits System.Web.Services.WebService #Region " Web Services Designer Generated Code " Public Sub New() MyBase.New() 'This call is required by the Web Services Designer. InitializeComponent() 'Add your own initialization code after the InitializeComponent() call End Sub 'Required by the Web Services Designer Private components As System.ComponentModel.IContainer 'NOTE: The following procedure is required by the Web Services Designer 'It can be modified using the Web Services Designer. 'Do not modify it using the code editor. <System.Diagnostics.DebuggerStepThrough()> Private Sub InitializeComponent() components = New System.ComponentModel.Container() End Sub Protected Overloads Overrides Sub Dispose(ByVal disposing As Boolean) 'CODEGEN: This procedure is required by the Web Services Designer 'Do not modify it using the code editor. If disposing Then If Not (components Is Nothing) Then components.Dispose() End If End If MyBase.Dispose(disposing) End Sub #End Region ' WEB SERVICE EXAMPLE ' The HelloWorld() example service returns the string Hello World. ' To build, uncomment the following lines then save and build the project. ' To test this web service, ensure that the .asmx file is the start page ' and press F5. '


'<WebMethod()> Public Function HelloWorld() As String 'HelloWorld = "Hello World" 'End Function End Class Después: Imports System.Web.Services <WebService(Namespace:="http://tempuri.org/")> _ Public Class Saludo Inherits System.Web.Services.WebService #Region " Web Services Designer Generated Code " Public Sub New() MyBase.New() 'This call is required by the Web Services Designer. InitializeComponent() 'Add your own initialization code after the InitializeComponent() call End Sub 'Required by the Web Services Designer Private components As System.ComponentModel.IContainer 'NOTE: The following procedure is required by the Web Services Designer 'It can be modified using the Web Services Designer. 'Do not modify it using the code editor. <System.Diagnostics.DebuggerStepThrough()> Private Sub InitializeComponent() components = New System.ComponentModel.Container() End Sub Protected Overloads Overrides Sub Dispose(ByVal disposing As Boolean) 'CODEGEN: This procedure is required by the Web Services Designer 'Do not modify it using the code editor. If disposing Then If Not (components Is Nothing) Then components.Dispose() End If End If MyBase.Dispose(disposing) End Sub #End Region ' WEB SERVICE EXAMPLE ' The HelloWorld() example service returns the string Hello World. ' To build, uncomment the following lines then save and build the project. ' To test this web service, ensure that the .asmx file is the start page ' and press F5. ' <WebMethod()> Public Function HelloWorld() As String HelloWorld = "Hello World Marco" End Function End Class 4.) Cambiar el nombre del archivo "Service1.asmx" a "mensaje1.asmx" a través del solution Explorer. Antes:


Después:

5.) Construir la solución. Ejecutar: "Build Solution" Menu: Build à "Build Solution", o bien, "Ctrl+Shift+B" Verificar en IIS que en "Default Web Site" está el sitio http://localhost/WorkShopUDP_v1

3 Testing Testing del webservice desde el browser


En el browser, abrir la dirección: http://localhost/WorkShopUDP_v1/mensaje1.asmx

Clickar sobre "HelloWorld"

Clickar "Invoke"

Consumo del webservice en aplicación .Net 1.) Crear proyecto Windows Application, llamado "testWebServiceHelloWorld"


2.) Agregamos referencia al webservice al proyecto: En el "Solution Explorer" pulsar botón derecho sobre "References" y "Add Web Reference" En la barra de direcciones de la ventana, agregar la dirección del webservice creado. http://localhost/WorkShopUDP_v1/mensaje1.asmx

Pulsando <ENTER>, comprobamos la existencia del webservice en la dirección ingresada.

Agregamos la referencia al proyecto: Click en "Add Reference".


Comprobar en el "Solution Explorer" la referencia agregada, y cambiar el nombre del fólder "localhost" a "wsSaludos" Antes:

Después:

3.) Comprobamos a través del explorador de Windows la existencia de los archivos "mensaje1.disco" y "mensaje1.wsdl" existen en el directorio "wsSaludos"


3.) Insertar un botón y un cuadro de texto al formulario

4.) En el código del formulario, importamos en espacio de nombres asociado a la referencia al webservice agregada.

5.) En el código de acción del botón, instanciamos un objeto de la clase "testWebServiceHelloWorld.wsSaludos", llamado "objWsSaludos". Dim objWsSaludo As New Saludo() 6.) Luego llamamos el método "HelloWorld" y asignamos su respuesta al TextBox1. TextBox1.Text = objWsSaludo.HelloWorld() Finalmente el código queda como: Imports testWebServiceHelloWorld.wsSaludos Public Class Form1 Inherits System.Windows.Forms.Form #Region " Windows Form Designer generated code " Public Sub New() MyBase.New() 'This call is required by the Windows Form Designer. InitializeComponent() 'Add any initialization after the InitializeComponent() call End Sub 'Form overrides dispose to clean up the component list. Protected Overloads Overrides Sub Dispose(ByVal disposing As Boolean) If disposing Then If Not (components Is Nothing) Then components.Dispose() End If End If MyBase.Dispose(disposing) End Sub


'Required by the Windows Form Designer Private components As System.ComponentModel.IContainer 'NOTE: The following procedure is required by the Windows Form Designer 'It can be modified using the Windows Form Designer. 'Do not modify it using the code editor. Friend WithEvents Button1 As System.Windows.Forms.Button Friend WithEvents TextBox1 As System.Windows.Forms.TextBox <System.Diagnostics.DebuggerStepThrough()> Private Sub InitializeComponent() Me.Button1 = New System.Windows.Forms.Button() Me.TextBox1 = New System.Windows.Forms.TextBox() Me.SuspendLayout() ' 'Button1 ' Me.Button1.Location = New System.Drawing.Point(184, 144) Me.Button1.Name = "Button1" Me.Button1.Size = New System.Drawing.Size(128, 32) Me.Button1.TabIndex = 0 Me.Button1.Text = "Aceptar" ' 'TextBox1 ' Me.TextBox1.Location = New System.Drawing.Point(32, 24) Me.TextBox1.Name = "TextBox1" Me.TextBox1.Size = New System.Drawing.Size(192, 20) Me.TextBox1.TabIndex = 1 Me.TextBox1.Text = "TextBox1" ' 'Form1 ' Me.AutoScaleBaseSize = New System.Drawing.Size(5, 13) Me.ClientSize = New System.Drawing.Size(432, 273) Me.Controls.AddRange(New System.Windows.Forms.Control() {Me.TextBox1, Me.Button1}) Me.Name = "Form1" Me.Text = "Form1" Me.ResumeLayout(False) End Sub #End Region Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click Dim objWsSaludo As New Saludo() TextBox1.Text = objWsSaludo.HelloWorld() End Sub End Class 6.) Construimos la solución, y pulsamos F5 para ejecutarla.

Al pulsar el botón, se invoca el webservice y se asigna el resultado al cuadro de texto.


Consumo de un web service desde ASP.Net Crear un proyecto ASP.Net Web Application

Agregar un botón y un cuadro de texto.

Agregar "Web Reference" al webservice http://localhost/WorkShopUDP_v1/mensaje1.asmx


Cambiar el nombre del directorio "localhost" a "wsSaludos"en el "Solution Explorer"

- En el código del webform, importar el espacio de nombres asociado al webservice. Imports testWSAsp.wsSaludos - En el código del botón, instanciar un objeto de la clase "Saludo", invocar la función "HelloWorld" asignando el resultado al TextBox1. Dim objWsSaludo As New Saludo() TextBox1.Text = objWsSaludo.HelloWorld Imports testWSAsp.wsSaludos Public Class WebForm1 Inherits System.Web.UI.Page Protected WithEvents TextBox1 As System.Web.UI.WebControls.TextBox Protected WithEvents Button1 As System.Web.UI.WebControls.Button #Region " Web Form Designer Generated Code " 'This call is required by the Web Form Designer. <System.Diagnostics.DebuggerStepThrough()> Private Sub InitializeComponent() End Sub Private Sub Page_Init(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Init 'CODEGEN: This method call is required by the Web Form Designer 'Do not modify it using the code editor. InitializeComponent() End Sub #End Region Private Sub Page_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load 'Put user code to initialize the page here End Sub Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click Dim objWsSaludo As New Saludo() TextBox1.Text = objWsSaludo.HelloWorld


End Sub End Class Construyendo la solución (Build) y ejecutando (F5):

Pulsando el botón:

Consumo de un web service desde aplicación móvil en .net - Instalar el "Mobile Internet Toolkit" para Visual Studio .NET - Instalar emulador de aplicación móvil. 1.) Crear proyecto "Mobile Web Application"

2.) Agregar controles móviles TextBox y Command.


3.) Agregar "Web Reference" al webservice http://localhost/WorkShopUDP_v1/mensaje1.asmx

Cambiar el nombre del directorio "localhost" a "wsSaludos"en el "Solution Explorer".

- En el código del Mobile Web Form, importar el espacio de nombres asociado al webservice. Imports MobileWebWSSaludo.wsSaludos - En el código del botón, instanciar un objeto de la clase "Saludo", invocar la función "HelloWorld" asignando el resultado al TextBox1. Dim objWsSaludo As New Saludo() TextBox1.Text = objWsSaludo.HelloWorld Imports MobileWebWSSaludo.wsSaludos Public Class MobileWebForm1 Inherits System.Web.UI.MobileControls.MobilePage Protected WithEvents Command1 As System.Web.UI.MobileControls.Command Protected WithEvents TextBox1 As System.Web.UI.MobileControls.TextBox Protected WithEvents Form1 As System.Web.UI.MobileControls.Form


#Region " Web Form Designer Generated Code " 'This call is required by the Web Form Designer. <System.Diagnostics.DebuggerStepThrough()> Private Sub InitializeComponent() End Sub Private Sub Page_Init(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Init 'CODEGEN: This method call is required by the Web Form Designer 'Do not modify it using the code editor. InitializeComponent() End Sub #End Region Private Sub Page_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load 'Put user code to initialize the page here End Sub Private Sub Command1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Command1.Click Dim objWsSaludo As New Saludo() TextBox1.Text = objWsSaludo.HelloWorld End Sub End Class Construyendo la solución (Build). Abrir el emulador abriendo la dirección de la página Mobiul Web Form.

Consumo de un web service desde Excel XP Instalar "Soap Toolkit" Instalar Office Webservices Referece Toolkit 1.) En el editor de Visual Basic Menu: Tools à Macro à Visual Basic Editor, o bien, Alt+F11 2.) Usando el webservice referente tool, agregar referencia al webservice Menu: Tools à Webservice Referentes Agregar URL asociada: http://localhost/WorkShopUDP_v1/mensaje1.asmx Pulsar "Search"


Agregar la referencia, seleccionando el checkBox y pulsar "Add"

Esto ha creado el módulo de clase "clsws_Saludo" (Proxy al Webservice) Ver Explorador del proyecto.


Insertar un módulo: Menu: Insert à Module

Agregar la función publica siguiente al módulo insertado: Public Function HelloMarco() As String Dim objWS As New clsws_Saludo HelloMarco = objWS.wsm_HelloWorld End Function


Probar la nueva function (HelloMarco) desde la planilla Excel.

Implementar código de Seguridad anti robots en ASP.NET Para crear un código de seguridad seguiremos los siguientes pasos: Tenemos que agregar en el formulario que deseamos insertar el código de seguridad los siguientes controles:

Una imagen (dónde su scr será /AntiRobots.aspx)

Un input de tipo texto, con un id= type= frm_Codigo_Seguridad

En el código VB de la página del registro declararemos una variable llamada bAntiBots #Region "Members" Dim bAntiBots As Boolean = False #End Region En el Page_Load:


If Not IsPostBack Then Session("AntiBots") = GenerateRandomCode() Else 'Comprobamos el código antibots If frm_Codigo_Seguridad.Value = Session("AntiBots").ToString() Then bAntiBots = True Else bAntiBots = False Me.Session("AntiBots") = GenerateRandomCode() End If End If Tenemos que crear la función GenerateRandomCode para generar un código de seguridad al azar #Region "GenerateRandomCode" Private Function GenerateRandomCode() As String Dim random As New Random Dim s As String = "" Dim i As Int32 = 0 Dim iChr As Int32 While (i <; 6) iChr = random.Next(48, 90) While iChr >; 57 And iChr <; 65 iChr = random.Next(48, 90) End While s = String.Concat(s, Chr(iChr).ToString()) i = i + 1 End While Return s End Function #End Region Para seguir, nos faltará crear la clase encargada de crear, manipular y deformar el código de seguridad generado en imagen Imports System Imports System.Drawing Imports System.Drawing.Drawing2D Imports System.Drawing.Imaging Imports System.Drawing.Text Public Class ImagenAntiBots Dim m_text As String Dim m_width As Int32 Dim m_height As Int32 Dim m_familyName As String Dim m_image As Bitmap Dim m_random As New Random #Region "Propiedades de lectura" Public ReadOnly Property Text() As String Get Return m_text End Get End Property Public ReadOnly Property Width() As Int32 Get Return m_width End Get End Property Public ReadOnly Property Height() As Int32 Get Return m_height End Get End Property Public ReadOnly Property Image() As Bitmap Get


Return m_image End Get End Property #End Region Public Sub New(ByVal s As String, ByVal width As Int32, ByVal height As Int32) Me.m_text = s Me.SetDimensions(width, height) Me.GenerateImage() End Sub Public Sub New(ByVal s As String, ByVal width As Int32, ByVal height As Int32, ByVal familyName As String) Me.m_text = s Me.SetDimensions(width, height) Me.SetFamilyName(familyName) Me.GenerateImage() End Sub Private Sub SetDimensions(ByVal width As Int32, ByVal height As Int32) If width <;= 0 Then Throw New ArgumentOutOfRangeException("width", width, "Argument out of range, must be greater than zero.") End If If (height <;= 0) Then Throw New ArgumentOutOfRangeException("height", height, "Argument out of range, must be greater than zero.") End If Me.m_width = width Me.m_height = height End Sub Private Sub SetFamilyName(ByVal familyName As String) Try Dim font As Font = New Font(familyName, 12.0F) Me.m_familyName = familyName font.Dispose() Catch ex As Exception Me.m_familyName = System.Drawing.FontFamily.GenericSerif.Name End Try End Sub Private Sub GenerateImage() Dim bitmap As New Bitmap(Me.m_width, Me.m_height, PixelFormat.Format32bppArgb) 'Creamos objeto grafico Dim g As Graphics = Graphics.FromImage(bitmap) g.SmoothingMode = SmoothingMode.AntiAlias Dim rect As New RectangleF(0, 0, Me.m_width, Me.m_height) 'Rellenamos el fondo Dim hatchBrush As New HatchBrush(HatchStyle.SmallConfetti, Color.LightGray, Color.White) g.FillRectangle(hatchBrush, rect) 'Establecemos la fuente Dim size As SizeF Dim fontSize As Single = rect.Height + 1 Dim font As Font 'Ajusta el tamaño de la fuente Do fontSize = fontSize - 1 font = New Font(Me.m_familyName, fontSize, FontStyle.Bold) size = g.MeasureString(Me.m_text, font) Loop While (size.Width >; rect.Width) 'Establece el formato de texto Dim format As New StringFormat format.Alignment = StringAlignment.Center format.LineAlignment = StringAlignment.Center Dim path As New GraphicsPath


path.AddString(Me.m_text, font.FontFamily, CType(font.Style, Int32), font.Size, rect, format) Dim v As Single = 4.0F Dim points As System.Drawing.PointF() = { _ New System.Drawing.PointF(m_random.Next(CType(rect.Width, Integer)) / v, m_random.Next(CType(rect.Height, Integer)) / v), _ New System.Drawing.PointF(rect.Width - m_random.Next(CType(rect.Width, Integer)) / v, m_random.Next(CType(rect.Height, Integer)) / v), _ New System.Drawing.PointF(m_random.Next(CType(rect.Width, Integer)) / v, rect.Height - m_random.Next(CType(rect.Height, Integer)) / v), _ New System.Drawing.PointF(rect.Width - m_random.Next(CType(rect.Width, Integer)) / v, rect.Height - m_random.Next(CType(rect.Height, Integer)) / v)} Dim matrix As New Matrix matrix.Translate(1, 3) 'Deformamos la imagen path.Warp(points, rect, matrix, 0) 'Dibuja el texto hatchBrush = New HatchBrush(HatchStyle.OutlinedDiamond, Color.Orange, Color.BlueViolet) g.FillPath(hatchBrush, path) 'Añade efectos Dim m As Int32 = Math.Max(CType(rect.Width, Integer), CType(rect.Height, Integer)) Dim i As Int32 = 0 While i <; CType((rect.Width * rect.Height / 30.0F), Int32) Dim x As Int32 = m_random.Next(CType(rect.Width, Integer)) Dim y As Int32 = m_random.Next(CType(rect.Height, Integer)) Dim w As Int32 = m_random.Next(CType(m / 50, Integer)) Dim h As Int32 = m_random.Next(CType(m / 50, Integer)) g.FillEllipse(hatchBrush, x, y, w, h) i = i + 1 End While font.Dispose() hatchBrush.Dispose() g.Dispose() 'Establece la imagen Me.m_image = bitmap End Sub End Class Ahora en el proyecto crearemos la página que apunta nuestra imagen (el primer control que hemos agregado en el proyecto, y en el Page_Load pondremos este código: Private Sub Page_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load 'Creamos una imagen creando el texto guardado en la sesion Dim ab As New ImagenAntiBots(Session("AntiBots").ToString(), 200, 50, "Arial") 'Cambiamos la respuesta al cliente a tipo "imagen/jpeg" Me.Response.Clear() Me.Response.ContentType = "image/jpeg" 'Salvamos la imagen en el Response ab.Image.Save(Me.Response.OutputStream, ImageFormat.Jpeg) End Sub Y para terminar, en el formulario del registro, dónde hemos agregado los controles, en el botón del submit, utilizar esta condición: If bAntiBots Then ' Creamos el registro Else ' El código de seguridad no está bien colocado End if Puedes descargarte todo el código fuente de pulsando aquí. [http://www.mistrucos.net/ficheros/trucos/652/antirobots.zip]


Autores del manual: Hay que agradecer a diversas personas la dedicación prestada para la creación de este manual. Sus nombres junto con el número de artículos redactados por cada uno son los siguientes:

Benjamín González C. Ingeniero de Sistemas (21 capítulos) Pol Salvat http://www.mistrucos.net/ (1 capítulo)

Todos los derechos de reproducción y difusión [http://www.desarrolloweb.com/copyright/] reservados a Guiarte

Multimedia S.L. [http://www.guiartemultimedia.com/]

Volver [http://www.desarrolloweb.com/manuales/54]


Servicios Web .Net

Documents

Transcript of Servicios Web .Net