Artculos tcnicos Grupo Danysoft:

Introduccin a Web Services con herramientas de desarrollo Microsoft

Por Oscar Gonzlez Moreno Equipo Grupo Danysoft abril de 2002 - (902) 123146 www.danysoft.com

Este documento se ha realizado utilizando Doc-To-Help, distribuido por :

Danysoft Internacional Avda de Espaa 17 28100 Alcobendas Madrid Tfno. 902.123146 Fax. 902.123145 http://www.danysoft.com http://www.danyshop.com danysoft@danysoft.com

Web Services con herramientas de desarrollo Microsoft. El mundo del desarrollo de aplicaciones en entorno Internet ha pasado por distintas etapas desde los albores del protocolo HTTP, los navegadores y los documentos HTML. En la ltima de ellas, que es la que vivimos actualmente, el panorama del desarrollo de aplicaciones I*Net se caracteriza por la gran sofisticacin que han alcanzado los servidores y las herramientas de desarrollo asociadas. Por un lado, desde el punto de vista del diseo, en el que contamos con herramientas visuales de todo tipo y editores HTML que haran las delicias de los viejos programadores de Bloc de notas. Por otro, desde el punto de vista del desarrollo, con lenguajes, libreras y generadores de cdigo de todo tipo, y con servidores web y de aplicaciones con infinidad de ayudas para el acceso a sistemas de base de datos, poolings de objetos, cach de pginas y datos, soporte transaccional, etc. Esta etapa ha dado mltiples aplicaciones y portales de gran calidad y rendimiento, y son muchos los desarrolladores que han dejado lo mejor de s en estos proyectos. Son muchas las exigencias de los usuarios y clientes en relacin a sus proyectos y desarrollos, y hoy en da, un portal vertical medio debe de trabajar con una serie de parmetros de velocidad, rendimiento, seguridad, navegabilidad y disponibilidad que hacen de los sistemas avanzados de desarrollo un elemento fundamental a la hora de conseguir la realizacin de las metas tecnolgicas fijadas. Pero si algo define a esta etapa desde un punto de vista negativo, es el aislamiento que vive cada uno de estos desarrollos. Cada vez que pensamos en realizar un portal vertical, pensamos en el pblico objetivo, en sus gustos y preferencias, en un diseo claro y eficaz, en una navegabilidad y en una usabilidad. Tambin trabajamos en un modelo de datos eficaz, en una capa de reglas de negocio extensible, y en un rendimiento global aceptable. Pero pocas veces pensamos en cmo va a comunicarse nuestro portal con el resto de Internet, y no hablamos de los clientes de Internet, los que entrarn en nuestro portal particular, sino que hablamos del RESTO de servidores de Internet.

FIGURA 1: El sitio web de Microsoft relativo a Web Services Con demasiada frecuencia orientamos nuestros desarrollos como un todo autocontenido del que nicamente saldr informacin a un navegador web en forma de pgina HTML y que recibir informacin por medio de un Back-Office (sistema de gestin) a medida. Esto nos lleva necesariamente a una gran contradiccin. En un mundo tan abierto y universal como lo es la red Internet, realmente tenemos un modelo de explotacin bastante limitado y atomizado. Un sitio web y otro nicamente se conocen por el sistema de hiperenlaces de HTML, y en algunas ocasiones por desarrollos a medida que vienen a hacer mas o menos lo mismo que ahora podremos realizar mediante los servicios web. Es algo similar a las polis de la antigua Grecia. Todas comparten un espacio comn, que a un visitante extranjero puede parecer como un todo, pero cada una de ellas conoce bien poco del resto, y el intercambio de informacin (bienes) entre una y otra se realiza de forma particular, sin orden ni concierto. Algunos sitios de Internet especializados en el suministro de informacin s que han pensado en este tipo de comunicacin o transmisin de datos entre portales, precisamente ocasionado por el tipo de servicio que estn ofreciendo, y habilitan direcciones URL (habitualmente de pago) que mediante el paso de unas serie de parmetros, devuelven informacin en distintos formatos (normalmente texto plano y documentos XML). Entre estos sitios uno de los mas conocidos es Reuters, suministrador de noticias y datos financieros. En este artculo veremos cmo esta situacin est a punto de cambiar. La tecnologa Web Services, que no es propietaria de Microsoft, pero en la que Microsoft .NET (con ASP .NET y Visual Studio .NET) tiene mucho que decir, hace posible desarrollar este tipo de aplicaciones de una forma estandarizada y mucho mas sencilla.

Un ejemplo prctico Las tecnologas, lenguajes y protocolos utilizadas para construir y utilizar un Servicio Web o Web Service puede que le suenen un poco extraas y que no haya trabajado nunca con ellas. Aunque tambin puede conocerlas de forma parcial (como conocer el lenguaje XML), pero no haber trabajado con ellas en conjunto. En realidad, un servicio web no se distingue mucho de una aplicacin clienteservidor de las de toda la vida. Al fin y al cabo, un cliente necesita obtener datos y realizar operaciones en un servidor, y para ello utilizar un sistema de llamada a procedimiento remoto, mediante una serie de protocolos y lenguajes bien conocidos. Bajo esta perspectiva, los servicios web no traen nada nuevo al mundo del desarrollo de aplicaciones. La diferencia fundamental est en las tecnologas que utilizaremos usando los servicios web. Si las anteriormente citadas aplicaciones cliente-servidor se desarrollaban de forma mas o menos aislada unas de otras, la particularidad fundamental de los servicios web es que todos utilizan una serie de protocolos y lenguajes comunes, haciendo as mucho mas sencilla la labor de interconectar unos con otros, y de construir aplicaciones cliente que sean capaces de entenderse con TODOS los servicios web que se construyan, ya estn realizados estos bajo tecnologa Microsoft o bajo otros sistemas. Nuestro primer paso por tanto ser un paso prctico, que consiste en construir un primer servicio web de ejemplo, para ver desde un punto de vista mas prctico las herramientas, lenguajes y protocolos que utilizamos y cmo lo utilizamos.

Visual Studio .NET Para el desarrollo de servicios web utilizaremos como herramienta fundamental Visual Studio .NET. Este entorno ofrece las herramientas necesarias para disear, desarrollar y mantener servicios web de una forma mucho mas sencilla de la que tendramos al programarlos desde cero. El desarrollo y puesta en produccin de servicios web en la plataforma Microsoft .NET no tiene porqu pasar obligatoriamente por el uso de Visual Studio .NET. Con un simple editor de textos podemos construir toda la programacin y ficheros de configuracin necesarios para la puesta en explotacin de un servicio web real, pero sin duda la utilizacin de este moderno entorno de desarrollo nos har la vida mucho mas sencilla a la hora de desarrollar nuestros servicios web. Por tanto, para construir nuestro primer servicio web, veremos primero los rudimentos de la escritura y utilizacin de los servicios web, pasando mas tarde a utilizar el entorno de Visual Studio .NET, que ser cuando podremos apreciar mucho mejor la cantidad de ayuda que nos brinda esta herramienta de desarrollo a la hora de construir Web Services.

Nuestro servicio web va a tratarse de un proveedor de informacin burstil, en el cual dado un cdigo de ndice de bolsa (IBEX por ejemplo), el sistema nos va a devolver su ultima cotizacin. Un servicio web desde en punto de vista del servidor IIS 5.0 funciona exactamente igual que una aplicacin web. Se aloja en un directorio virtual, y utiliza para su funcionamiento archivos .ASMX, en vez de las pginas .ASPX que utilizamos en ASP .NET. Por eso, nuestro primer paso va a ser el construir un directorio virtual en nuestro servidor web. Para ello, siga los siguientes pasos (si usted ya conoce la mecnica de aadir un directorio virtual a IIS 5.0, los siguientes puntos le resultarn un poco obvios:

1) Crear un directorio fsico donde almacenaremos los ficheros necesarios para el funcionamiento de nuestro servicio web. Suponiendo que su directorio raz de su servidor web IIS 5.0 sea el directorio raz por defecto (c:\inetpub\wwwroot\), crearemos un nuevo directorio llamado trade_service. 2) Ejecutar la consola de administracin de IIS 5.0 (MMC). Esta se encuentra en el Panel de Control, icono de Herramientas Administrativas e icono de Administrador de Servicios de Internet. 3) Seleccionamos y desplegamos la rama del Servidor Web Predeterminado, y veremos nuestra carpeta denominada trade_service. 4) Haremos clic con el botn derecho sobre esta carpeta, y elegiremos la opcin Propiedades. 5) En la pestaa Directorio, pulsaremos el botn de Crear. Esta operacin lo que realiza es crear una nueva aplicacin web de IIS 5.0 en este directorio fsico. A partir de este momento, podremos acceder a la direccin http://localhost/trade_service, e IIS 5.0 nos la servir dentro del marco que el define para las aplicaciones web. 6) Pulsamos Aceptar y salimos de todas las ventanas. Estos pasos todava no tienen nada que ver con la construccin de un servicio web. Ahora es cuando tenemos que afrontar la verdadera tarea de codificar nuestro primer servicio web. Para ello, crearemos un fichero llamado dispatcher.asmx. Aunque es una cuestin muy personal, yo aconsejo siempre utilizar una terminologa inglesa a la hora de nombrar pginas y recursos. Esto le da una universalidad mucho mayor a nuestros desarrollos, que nunca se sabe quin los continuar en un futuro. En este caso, el trmino dispatcher lo utilizaremos por su acepcin de suministrador. Nota: Este primer servicio web lo vamos a desarrollar utilizando el lenguaje C#. Su construccin ser muy similar en VB, y daremos el cdigo fuente necesario para que pueda ver las diferencias de sintaxis entre uno y otro. Esto nicamente lo haremos con el cdigo inicial (el que vemos a continuacin) por motivos de espacio y legibilidad. En cualquier caso, si usted est mas interesado en la versin de VB, tampoco le ser mucha molestia el seguir el desarrollo en C#, ya que resulta muy similar.

El cdigo de nuestra pgina dispatcher.asmx es el siguiente:

PAGINA: dispatcher.asmx
<%@ WebService Language="c#" Class="danysoft_articles.trader_service" %> using System; using System.Web; using System.Web.Services; namespace danysoft_articles { [WebService(Namespace="http://localhost/trade_service/")] public class trader_service : System.Web.Services.WebService { public trader_service() { } [WebMethod]

public string getProductPrice( string pProduct ) { return "Codigo de producto no valido"; } } }

El cdigo en Visual Basic .NET (VB) de este mismo servicio web, el el siguiente:
<%@ WebService Language="VB" Class="trader_service" %> Imports System Imports System.Web Imports System.Web.Services <WebService(Namespace:="http://localhost/trade_service/")> trader_service Public Class trader_service Inherits System.Web.Services.WebService Public Sub New() MyBase.New() End Sub <WebMethod()> Public Function getProductPrice( byVal as String Return "Codigo de producto no valido" End Function End Class pProduct as String) Public Class

Como podemos ver, ambas versiones son bastante similares. Este listado (volvemos a referirnos al realizado mediante C#) representa la parte de servidor de nuestro Web Service. Pero todava tenemos que probarlo. Para ello, abriremos un navegador (Internet Explorer por ejemplo) y solicitaremos la siguiente URL: http://localhost/trade_service/dispatcher.asmx. Al realizar esta operacin, en nuestro navegador web veremos una figura como la de la figura 2. Esta pgina HTML ha sido construida por el sistema ASP .NET, que ha ledo la informacin de nuestro servicio web y nos ha devuelto dicho documento HTML. En el, se presentan dos enlaces. Uno nos indica que podemos utilizar un mtodo llamado getProductPrice, y el otro nos ofrece informacin WDSL sobre la definicin formal de nuestro servicio Web.

Fig 02 Resultado en el navegador del servicio Web

Si hacemos clic sobre el primero de ellos, el sistema har una peticin a nuestro documento dispatcher.asmx (el mismo que hemos utilizado anteriormente), y le pasar por el mtodo GET el parmetro op=getProductPrice. La URL resultante es: http://localhost/trade_service/dispatcher.asmx?op=getProductPrice. Ahora nosotros podemos probar a solicitar otro mtodo distinto a getProductPrice. Solicitemos por ejemplo la siguiente URL: http://localhost/trade_service/dispatcher.asmx?op=getProductPrice2. Como podremos comprobar, el sistema nos informa de que no ha encontrado ningn mtodo correspondiente a este nombre en nuestro servicio web. Nota: Los mtodos exportables por el servicio web tienen que ser del tipo Public. Si probamos a marcar nuestro mtodo getProductPrice como Private, el sistema tampoco lo encontrar y dar un mensaje como el anterior. Una vez que hemos solicitado un mtodo vlido, y que el servicio web nos ha respondido, tendremos en nuestro navegador una nueva pgina HTML con un formulario, que nos deja introducir los valores necesarios para cada parmetro que el sistema haya encontrado para el mtodo solicitado. De forma adicional, esta pgina HTML tambin nos ofrece el cdigo fuente de las llamadas SOAP, GET y POST necesaria para utilizar este mtodo. Estos tres listados corresponden al cdigo que tendramos que enviar al servidor Web para que utilizar los servicios de nuestro servidor web, y mas concretamente, del mtodo que nos ocupa (getProductPrice). En el caso de las llamadas GET y POST, son simplemente las llamadas que el sistema de Web Services acepta

como compatibilidad con el protocolo HTTP, y consta de un sencillo paso de parmetros por variable. Estas peticiones tipo son las siguientes: Mtodo GET: GET /trade_service/dispatcher.asmx/getProductPrice?pProduct=string HTTP/1.1 Host: localhost

Mtodo POST: POST /trade_service/dispatcher.asmx/getProductPrice HTTP/1.1 Host: localhost Content-Type: application/x-www-form-urlencoded Content-Length: length pProduct=string Como podemos observar, se trata de peticiones que guardan el formato habitual de ambos sistemas de peticin de URL a un servidor web. Las variables string y length se debern sustituir en tiempo de ejecucin por los valores de parmetro de pProduct (cdigo del producto de la bolsa que queremos consultar) y la longitud de nuestra peticin POST respectivamente.

De forma adicional, el sistema nos muestra qu tipo de respuesta tipo obtendramos para estas peticiones. Tanto para el sistema POST como para GET, la respuesta sera la siguiente, con el mismo sistema de reemplazar las variables string y length: HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Content-Length: length <?xml version="1.0" encoding="utf-8"?> <string xmlns="http://localhost/trade_service/">string</string>

Sin embargo, si queremos utilizar el protocolo SOAP, tendremos que recurrir a un cliente SOAP que realice una peticin basada en este formato, basado a su vez en un documento XML. La pgina de resultado de nuestro servicio web tambin nos ofrece informacin sobre la peticin SOAP que debemos de realizar para utilizar nuestro servicio con la operacin getProductPrice. Este documento XML es el siguiente: POST /trade_service/dispatcher.asmx HTTP/1.1 Host: localhost Content-Type: text/xml; charset=utf-8 Content-Length: length

SOAPAction: "http://localhost/trade_service/getProductPrice" <?xml version="1.0" encoding="utf-8"?> <soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <getProductPrice xmlns="http://localhost/trade_service/"> <pProduct>string</pProduct> </getProductPrice> </soap:Body> </soap:Envelope>

Como se puede observar, consta de dos partes bien diferenciadas por una lnea en blanco. La primera se trata de una cabecera de peticin POST normal y corriente (bajo el protocolo HTTP 1.1), con una cabecera especial, que no se encuentra normalmente en las peticiones de pgina de los navegadores, que se denomina SOAPAction, y que contiene la URL que estamos solicitando. El cuerpo de la peticin (BODY) es un documento XML bien formado, que adems de definir los esquemas XML (XMLSchema) que est utilizando, define una seccin soap:Body que se encarga de solicitar una operacin en concreto getProductPrice y suministrar un valor para el nico parmetro que acepta esta funcin (pProduct). El tipo de resultado que obtendr el cliente SOAP al realizar una peticin de este tipo tambin viene especificado, y ser como el siguiente: HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Content-Length: length <?xml version="1.0" encoding="utf-8"?> <soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <getProductPriceResponse xmlns="http://localhost/trade_service/"> <getProductPriceResult>string</getProductPriceResult> </getProductPriceResponse> </soap:Body> </soap:Envelope> Encapsulado de igual forma bajo el protocolo HTTP 1.1, el servidor web nos devuelve otro documento SOAP en el que se incluye un elemento llamado getProductPriceResponse, resultado automtico de aadir el literal Response al mismo nombre de operacin que hemos solicitado (getProductPrice). Este elemento incluye informacin sobre el espacio de nombres que estamos utilizando (http://localhost/trade_service), e incluye a su vez otro elemento XML con el resultado de la operacin, con el nombre de elemento resultante de anexar el literal Result de nuevo al nombre de operacin que hemos solicitado.

Realizando la peticin al servidor Como vemos, el sistema de servicios web implementado en Microsoft .NET nos ofrece una gran cantidad de informacin de ayuda a la hora de querer nosotros implementar nuestros clientes, ya sea mediante GET, POST o SOAP. Pero como ultima ayuda, el sistema tambin nos presenta un formulario en el que podemos rellenar los parmetros necesarios de la operacin que estamos ejecutando. Si escribimos un valor en la casilla correspondiente a el parmetro pProduct, y hacemos clic en el botn de Invoke, el sistema realizar una llamada mediante el sistema GET a nuestro servicio web, que nos devolver el correspondiente documento XML con el resultado de la operacin. Nota: El resultado de todas las operaciones por ahora devuelve un nico valor de Cdigo de producto no valido. En el siguiente apartado aprenderemos a cmo integrar lgica de negocio en nuestro servicio web para que funcione de una forma mas real.

Un servicio Web no tiene porqu estar necesariamente ligado a un navegador de Internet. Cualquier aplicacin en cualquier otro lenguaje o plataforma, que sea capaz de abrir una comunicacin TCP/IP mediante HTTP puede ser capaz de enviar y recibir peticiones y respuestas SOAP e integrar los documentos XML en su propio funcionamiento. Por esta razn es por la que se dice que los servicios web XML son una solucin multiplataforma, porque lo nico que se intercambia es un documento XML, basado eso s en unos esquemas determinados, y que cualquier aplicacin o sistema en cualquier sistema operativo puede entender.

Resumen Entre los servicios web que una empresa puede desarrollar, hay varios que resultan de especial inters. En un primer momento, la mayora de empresas seguramente comenzarn por la mera publicacin de su informacin en la red. Servicios de noticias, informacin burstil o cualquier otro tipo de informacin tipo B2C (Business to Consumer) sern los servicios web mas comunes. Pero estos servicios web tambin pueden ser utilizados en entornos B2B, aprovechando las caractersticas cross-platform inherentes a los mismos. As, la publicacin de agendas, informacin corporativa, gestin de fuerza de ventas, gestin de almacenes, envos, etc. ser posible gracias a la universalidad de los servicios web. La construccin de servicios web con las herramientas que Microsoft pone a nuestra disposicin, lideradas por el entorno de desarrollo Visual Studio, es una tarea sencilla aunque potente a la vez. No queda mucho tiempo para que los servicios web se hagan mas y mas populares en Internet, y de seguro que muchos proveedores de informacin ya estn trabajando en migraciones hacia este nuevo sistema. Por ahora, la alternativa de Microsoft parece la mas avanzada en este campo, y tendremos que esperar todava algn tiempo para ir viendo cmo se suceden los acontecimientos en este nuevo mercado de aplicaciones web que nos llega. Hasta entonces. Dejar un comentario Puede enviarnos cualquier comentario sobre este tema a boletines@danysoft.com, estaremos encantados de recibirlo.