5.

Programacin de Servicios Web

5.1. Introduccin a los Servicios Web
Hasta ahora el desarrollo de aplicaciones Web consista en crear programas que se encargan de dar servicio a un cliente de tipo navegador, por lo que las respuestas generadas desde la aplicacin estaban siempre orientadas a la presentacin de resultados en una pantalla. Este esquema, aunque ofrece muchas posibilidades (consultas de informacin, altas de usuarios, compras por Internet, etc) presenta tambin muchas limitaciones ya que la informacin procedente de la aplicacin slo puede ser utilizada para su visualizacin. Los servicios Web pretenden dar un paso ms en desarrollo de aplicaciones para la Web, ya que su objetivo es que estas puedan ser utilizadas por otros programas capaces de procesar las respuestas con otro fin que no sea el de la presentacin de informacin en pantalla, permitiendo adems automatizar ciertos procesos en la Web al posibilitar transacciones de datos sin la intervencin del usuario. Conceptos bsicos sobre la arquitectura de servicios Web Este nuevo modelo de arquitectura, conocido tambin como Arquitectura Orientada al Servicio (SOA), se basa en proporcionar soluciones a problemas concretos. Estas soluciones se encapsulan como un "servicio" y se exponen en la Red para que sean accesibles a otras aplicaciones. Al disponer de estas soluciones o servicios, las aplicaciones pueden centrarse en resolver problemas de mayor nivel. Desde un punto de vista programtico, un servicio Web consiste en un componente software que expone un conjunto de operaciones en la Web (mtodos), que pueden ser utilizadas desde otros programas. As como las aplicaciones Web tradicionales estn desarrolladas para que puedan ser utilizadas por un cliente tipo navegador, los servicios Web representan un paso ms en la escala evolutiva del software para Internet, ya que pueden ser invocados por otros programas sin la intervencin de un usuario. Caractersticas de los servicios Web Ciertamente, la comunicacin programa-programa en un entorno distribuido no es una idea novedosa introducida con los servicios Web. Otras tecnologas ms antiguas, como CORBA o DCOM, permiten implementar este tipo de soluciones de forma ms o menos exitosa, aunque con ciertas limitaciones en unos casos y con excesiva complejidad en otros.
Captulo 5. Programacin de Servicios Web Pgina 1

Sin embargo, los servicios Web poseen una serie de caractersticas que los hacen preferibles a estas otras tecnologas. Entre ellas cabe destacar: Utilizacin de estndares existentes. La base de la arquitectura de servicios Web la constituye el protocolo HTTP y el estndar XML. De hecho, la comunicacin cliente-servicio Web se lleva a cabo mediante el intercambio de documentos XML entre ambos, utilizando HTTP como protocolo de comunicacin. Ver figura.

Independencia de la plataforma. La utilizacin de XML como formato de intercambio de informacin entre el cliente y el servicio Web permite que la comunicacin entre ambos pueda realizarse independientemente de la tecnologa o lenguaje con el que tanto uno como otro estn implementados, as como de la plataforma en la que se ejecuten. Nuevos estndares abiertos. HTTP y XML constituyen la base principal de los servicios Web. No obstante, se han desarrollado una serie de tecnologas que permiten estandarizar operaciones como la descripcin o la publicacin de un servicio Web. Estas tecnologas han sido ampliamente aceptadas por la gran mayora de fabricantes software, que adems las han incluido en sus plataformas y soluciones.

Estructura interna de un servicio Web La estructura y complejidad de un servicio Web depende de las funciones a realizar y del tipo de servicio que se trate. En cualquier caso se pueden distinguir dos componentes bsicos: Componente software. Se trata de componentes de cdigo reutilizable que implementan la funcionalidad del servicio, sus mtodos pueden incluir acceso a diferentes fuentes de datos. La funcionalidad que proporcionan puede ser compartida por el resto
Pgina 2

Captulo 5. Programacin de Servicios Web

de mdulos que forman parte de la aplicacin Web. Estos componentes pueden estar implementados con cualquier tecnologa software; en el caso de .NET esta funcionalidad estara implementada mediante clases independientes compiladas en un ensamblado dll, mientras que en el caso, por ejemplo, de J2EE, podran estar implementados mediante uno o varios Enterprise JavaBeans.

Servidor SOAP. Hace de interfaz entre el cliente y el componente que implementa el servicio. La comunicacin entre el cliente y el servicio Web se realiza va XML, utilizando un protocolo de codificacin conocido como SOAP. As que por un lado este mdulo debe encargarse de decodificar las peticiones SOAP que llegan desde el cliente e invocar a los mtodos del componente, mientras que por otro, debe codificar los resultados devueltos por el componente en mensajes SOAP y enviarlos al cliente. En .NET esta labor se llevara a cabo mediante pginas aspx dentro de una aplicacin ASP.NET, mientras que en J2EE podra implementarse a travs de servlets y pginas JSP.

Como veremos, el entrono de desarrollo Visual Studio.NET proporciona un tipo de proyecto que posibilita la generacin automtica de estos componentes a partir de la definicin de los mtodos que el servicio Web debe exponer. Tipos de servicios Web En funcin de cmo va a ser procesada la informacin por un servicio Web, podemos dividir estos en dos categoras: Servicios Web orientados a mtodo y Servicios Web orientados a documento. Servicios Web Orientados a Mtodo. Se basan en una interaccin de tipo Invocacin Remota a Mtodo (RPC), donde el documento XML de peticin del servicio Web representa la llamada a un mtodo o procedimiento con sus correspondientes parmetros de entrada, mientras que el documento XML generado como respuesta representa el valor devuelto por dicho mtodo.

Es el caso ms sencillo de servicio Web y el ms utilizado, donde cliente y servicio se comunican de forma sncrona.

Captulo 5. Programacin de Servicios Web

Pgina 3

 Servicios Web Orientados a Documento. El documento XML enviado por el cliente al servicio Web es procesado por este en su totalidad. Este proceso se lleva a cabo de forma asncrona y el mismo puede implicar llamadas a diferentes mtodos y procedimientos en los componentes del servidor. Un ejemplo de este tipo de servicios podra ser un servicio Web para procesamiento de rdenes de compra. En este caso el cliente enva al servicio Web un documento XML con el cdigo del producto a comprar, los datos bancarios y la direccin de envo. Una vez decodificado el mensaje, el servicio Web comienza a ejecutar las diferentes tareas, como la comprobacin de los datos bancarios del cliente, notificar el pedido al repartidor, etc. Finalmente, el servicio Web enva un documento de respuesta con la confirmacin o rechazo de la orden de compra que es a su vez interpretado por la aplicacin cliente. La llamada a este tipo de servicios Web se realiza de forma asncrona, lo que significa que el cliente puede continuar su ejecucin mientras el servicio Web procesa el documento. Roles en la arquitectura de servicios Web Aunque hasta ahora se ha hablado nicamente de clientes y servicios, la arquitectura de servicios Web est basada en las interacciones entre tres elementos que constituyen los roles principales dentro del modelo. Ver figura.

Estos son: Cliente del servicio. Se trata de la aplicacin usuaria del servicio. Los clientes se comunican con el servicio a travs de mensajes XML que son transmitidos a travs de HTTP. Proveedor de servicio. El proveedor de servicio es la plataforma que hospeda el servicio y da acceso al mismo. Una vez que el servicio Web est implementado, el proveedor de servicio define una descripcin con sus caractersticas y lo publica para que sea accesible por los clientes.

Captulo 5. Programacin de Servicios Web

Pgina 4

Registro de servicios. Se trata de un elemento opcional dentro de la arquitectura de servicios Web. El registro de servicios contiene la descripcin de los servicios publicados por los distintos proveedores. Los clientes pueden utilizar este registro para localizar un servicio Web y obtener informacin del mismo, como quin es el proveedor del servicio, qu protocolos utiliza y en general cualquier informacin vlida que permita al cliente invocarlo.

Captulo 5. Programacin de Servicios Web

Pgina 5

5.2. Estndares de la arquitectura de servicios Web

Como ya se ha visto, la arquitectura de servicios Web se basa en la utilizacin de XML como mecanismo para intercambio de datos. Basndose en esta tecnologa, se han definido una serie de estndares para posibilitar la interaccin entre los diferentes roles que forman la arquitectura. Estos estndares son: SOAP, WSDL y UUDI. 5.2.1. SOAP SOAP (Simple Object Access Protocol) es un protocolo definido por el W3C para el intercambio de informacin entre aplicaciones en un entorno distribuido. SOAP est basado en XML y define los formatos de los documentos XML (mensajes SOAP) que van a intercambiarse las aplicaciones. En el caso de un servicio Web basado en RPC, SOAP define el formato del documento XML que la aplicacin cliente debe utilizar para invocar a los mtodos del servicio y los parmetros de entrada necesarios, as como el formato del documento XML generado como respuesta a la llamada. Aunque los mensajes SOAP pueden ser utilizados en combinacin con diferentes protocolos de red, la definicin actual nicamente abarca HTTP. Partes de un mensaje SOAP Tal y como se refleja en la figura 136, un mensaje SOAP est formado por tres partes: Envelope. El elemento Envelope es el elemento principal del documento, por lo que debe estar presente en todos los mensajes. Envelope incluye las referencias a los espacios de nombres utilizados por el documento y tambin puede incluir algunos atributos adicionales, como encodingStyle, atributo que indica las reglas para serializacin de los datos utilizados en el mensaje SOAP. Header. Se trata de un elemento opcional; si aparece debe ser el primer elemento hijo de Envelope. Dado que un mensaje SOAP puede atravesar diversos nodos hasta llegar a su destino, Header puede utilizarse para suministrar algn tipo de informacin adicional a esos nodos. Body. Este elemento contiene la parte principal del mensaje SOAP. Para los mensajes de tipo RPC, Body contiene las llamadas y respuestas a procedimientos remotos. En los servicios Web orientados a documento, este elemento contiene el documento XML que va a ser procesado por el servicio. Estructura de un mensaje SOAP:
Captulo 5. Programacin de Servicios Web Pgina 6

<SOAP-ENV: envelope...> <SOAP-ENV:Header> <!--Informacion adicional--> </SOAP-ENV: Header> <SOAP-ENV: Body> <!--cuerpo del mensaje--> </SOAP-ENV: Body> </SOAP-ENV: envelope> SOAP en RPC Una de las principales aplicaciones de SOAP es la encapsulacin de llamadas a procedimientos remotos en documentos XML. En estos casos, d elemento Body debe tener las siguientes caractersticas: Cuando se trate de un mensaje de llamada a mtodo, Body debe contener un elemento cuyo nombre coincida con el nombre del mtodo llamado. Dicho elemento debe contener en sus subelementos los valores de los parmetros de entrada del mtodo. Por ejemplo, para invocar al siguiente mtodo: public float GetPrecio(string codigo) La estructura de Body debera ser la indicada a continuacin: <SOAP-ENV: Body> <GetPrecio xmlns= www.miesquema.com"> <codigo>DIS</codigo> </GetPrecio> </SOAP-ENV: Body> En el caso de los mensajes de respuesta, Body debe contener un elemento de respuesta al mtodo. El nombre de este elemento puede ser cualquiera aunque por convenio se utiliza la palabra Response precedida del nombre del mtodo. Si el mtodo devuelve un valor este debera incluirse en un subeIemento del anterior, siendo tambin irrelevante el nombre de este elemento. La estructura del Body del mensaje de respuesta en el ejemplo anterior quedara como se indica a continuacin:

Captulo 5. Programacin de Servicios Web

Pgina 7

<SOAP-ENV: Body> <GetPrecioResponse xmlns="www.miesquema.com"> <Precio> 34. 5</Precio> </GetPrecioResponse> </SOAP-ENV: Body> 5.2.2. WSDL Para que un cliente pueda interactuar con un servicio Web es necesario que este est descrito de alguna manera. WSDL o Lenguaje de Descripcin de Servicios Web es una especificacin basada en XML, utilizada para la descripcin de servicios Web. Los proveedores de servicios Web utilizan WSDL para generar un documento XML en el que describen las caractersticas del servicio que ofrecen. Los clientes del servicio Web utilizan este documento para obtener la informacin necesaria que les permita utilizarlo. Normalmente no ser necesario generar dicho documento de forma manual, ya que muchas de las herramientas existentes para la creacin de servicios Web son capaces de generar directamente el documento WSDL correspondiente. Un documento WSDL describe: Los mtodos proporcionados por el servicio. Los parmetros de entrada y salida. Cmo conectarse con el servicio. Estructura de un documento WSDL Todo documento WSDL est formado por un elemento raz llamado definitions. En l se declaran los diferentes espacios de nombres utilizados por el documento. Ver figura abajo. Un espacio de nombres representa a su vez un documento en el que se encuentran definidas las reglas de utilizacin de un determinado grupo de etiquetas.

Captulo 5. Programacin de Servicios Web

Pgina 8

El resto de subelementos incluidos en definitions para la descripcin del servicio son types, message, portType, binding y service. A continuacin describimos el significado de los diferentes elementos definidos en definitions: types. Se utiliza para definir los tipos de datos que van a ser utilizados por el servicio, tanto en lo que se refiere a parmetros de mtodos como a valores devueltos por estos. Ver figura. En la definicin de estos elementos se utiliza la especificacin XML Schema. Cuando se trate de tipos de datos bsicos (int, string, etc.) no es necesario definir nuevos tipos basados en estos, ya que podr hacerse referencia directamente a los tipos de datos Schema desde el elemento message. message. Los elementos message representan la informacin (mensajes) que va a ser intercambiada entre los mtodos del servicio Web y los clientes. Ver esquema. Cada message tiene un subelemento part que describe el tipo de datos utilizado por el mensaje. Esquema definicin types:

Captulo 5. Programacin de Servicios Web

Pgina 9

Esquema descripcin de los mensajes:

portType. El elemento portType describe las operaciones expuestas por el servicio Web. Cada operacin est definida con el elemento operation y llevar asociado un mensaje de entrada y otro de salida. En los servicios Web basados en RPC, las operaciones son los mtodos expuestos por el servicio. En el ejemplo utilizado anteriormente, el elemento portType quedara tal y como se indica en la figura de la siguiente pgina binding. Una vez definidas las operaciones que va a realizar el servicio es necesario vincularlas a un protocolo concreto. Esta es la labor realizada por el elemento binding, en donde se especifica el tipo de transporte utilizado (SOAP, HTTP, POST, etc.) y los accesos de red necesarios para ejecutar una determinada operacin, tal y como queda reflejado en la figura de la siguiente pgina. Esquema portType:

Esquema binding:
Captulo 5. Programacin de Servicios Web Pgina 10

 service. Finalmente, es necesario especificar la direccin o punto de entrada al servicio Web, informacin que se incluye dentro del elemento service. Mediante el subelemento port se especifica la direccin de cada elemento binding. En el caso de SOAP, esta direccin es indicada con el atributo location del elemento address.

5.2.3. UDDI UDDl (Universal Description Discovery and Integration proyect) es una especificacin que define cmo publicar y localizar un servicio Web en un registro de servicios compatible con UDDI. A un registro UDDl pueden acceder dos tipos de clientes: Proveedores de servicio. Acceden al registro para publicar sus servicios. UDDI proporciona mecanismos para que los proveedores "cuelguen" en el registro las descripciones de sus servicios Web.

Captulo 5. Programacin de Servicios Web

Pgina 11

 Clientes de servicios. Utilizan el registro para localizar un servicio y poder hacer uso de l (vinculacin al servicio). UDDl soporta mecanismos de bsqueda de servicios. UDDI utiliza mensajes SOAP para publicar, editar y buscar informacin en el registro. Mediante un esquema XML se definen los distintos tipos de datos que pueden ser enviados al registro y recibidos desde este. De hecho, la especificacin UDDl est compuesta por dos partes: Un esquema UDDI. Identifica los tipos de estructuras de datos XML que componen una entrada de registro para un servicio Web. Un API UDDI. Describe los mensajes SOAP utilizados para publicar y localizar una entrada del registro.

Prctica: Creacin de Servicios Web con Visual Studio Visual Studio.NET dispone de una plantilla especial para la creacin de servicios Web; dado que se trata de un caso especial de aplicacin Web, deben ser construidos sobre un proyecto de tipo Web Site. As pues, para crear un servicio Web, primeramente debemos seleccionar la opcin de men Sitio Web Despus, en la pantalla de nuevo sitio Web elegiremos el icono Servicio Web ASP.NET, asignando un nombre y una ubicacin a la aplicacin. Una vez creado el proyecto, podemos comprobar que el elemento principal de una aplicacin de tipo servicio Web es la pgina asmx. Una pgina asmx es similar a una aspx pero sin interfaz grfica. Dispone de un archivo de cdigo asociado en el que se define una clase que hereda WebService. En esta clase es donde se implementarn los mtodos de negocio que el servicio Web expondr a las aplicaciones. Cada uno de estos mtodos deber estar declarado con el atributo [WebMethod], tal y como puede apreciarse en el mtodo HelloWorld() que incluye por defecto la subclase de WebService y cuyo cdigo se indica a continuacin:
using using using using using using System; System.Linq; System.Web; System.Web.Services; System.Web.Services.Protocols; System.Xml.Linq;

[WebService(Namespace = "http://tempuri.org/")] [WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]

Captulo 5. Programacin de Servicios Web

Pgina 12

// Para permitir que se llame a este servicio web desde un script, usando ASP.NET AJAX, quite la marca de comentario de la lnea siguiente. // [System.Web.Script.Services.ScriptService] public class Service : System.Web.Services.WebService { public Service () { //Eliminar la marca de comentario de la lnea siguiente si utiliza los componentes diseados //InitializeComponent(); } [WebMethod] public string HelloWorld() { return "Hello World"; } }

Vamos a aadir un segundo mtodo llamado LongitudCadena(), que recibir como parmetro una cadena de caracteres y devolver como resultado el nmero de caracteres de la misma:
[WebMethod] public int LongitudCadena(string Cadena) { return Cadena.Length; }

La implementacin de los mtodos de negocio en esta clase es la nica tarea que debe realizar el programador de un servicio Web, pues el .NET Framework se encargar de crear toda la infraestructura necesaria para que el servicio Web sea accesible a las aplicaciones clientes a travs de SOAP/XML, todo ello de forma transparente para el programador. Una vez completada la codificacin de los mtodos podemos probar el funcionamiento de los mismos desde Visual Studio.NET. Si pulsamos el botn de ejecucin (F5), se abrir una instancia del navegador y se enviar una solicitud de la pgina .asmx de la aplicacin, publicada en el emulador del servidor Web que incorpora Visual Studio. Se visualizar entonces en el navegador una pgina similar a la mostrada a continuacin:

Captulo 5. Programacin de Servicios Web

Pgina 13

Aunque un servicio Web no est pensado para ser utilizado por un navegador, las pginas asmx generan dinmicamente una pgina HTML cuando detectan una solicitud procedente de un navegador. Esta pgina permite probar el funcionamiento de los mtodos del servicio Web antes de ponerlo en produccin. Como podemos ver, la pgina dispone de un enlace que nos permite acceder a la pgina WSDL de descripcin del servicio Web. Adems, existe un enlace para cada uno de los mtodos expuestos por el servicio Web, a travs de los cuales podemos acceder a una pgina donde se nos solicitarn los parmetros de llamada al mtodo mediante unos controles. En esta pgina tambin se nos muestra cmo ser el documento XML que ser enviado como llamada al mtodo, as como el que este generar en la respuesta. Al pulsar el botn "Invoke" se simular la llamada SOAP al mtodo con los parmetros indicados, mostrndose una nueva pgina en la que figura un pequeo documento XML con el resultado de la llamada, lo que nos permitir comprobar si el mtodo funciona o no correctamente. Una vez verificado el funcionamiento de los mtodos, el servicio Web se encuentra listo para ser desplegado en el servidor Web de produccin, debiendo seguir exactamente los mismos pasos que se utilizan para el despliegue de las aplicaciones ASP.NET estndares.

Captulo 5. Programacin de Servicios Web

Pgina 14

5.3. Aplicaciones cliente de un servicio Web

Si resulta sencillo construir y desplegar un servicio Web con Visual Studio.NET, no lo es menos la creacin de aplicaciones clientes. Como veremos, para crear una aplicacin que haga uso de los mtodos de un servicio Web publicado en un servidor remoto, el programador no tendr que preocuparse de los detalles relativos a la generacin de mensajes XML para invocacin a los mtodos ni de la decodificacin de los documentos de respuesta, puesto que todos estos aspectos son manejados directamente por Visual Studio haciendo que resulten transparentes para el programador. De este modo, la utilizacin de un servicio Web por parte de una aplicacin .NET resultar ser una tarea similar al empleo de cualquier clase estndar. Clases proxy Para comunicar una aplicacin con un servicio Web remoto, la plataforma .NET hace uso de las llamadas clases proxy. Una clase proxy es una clase que sirve de interfaz entre el cliente y el servicio Web, exponiendo los mismos mtodos de este a la aplicacin, a fin de que pueda invocar a los mtodos del servicio Web utilizando un objeto local. De esta forma, la aplicacin no tendr que preocuparse de los detalles XML/SOAP. Ver esquema:

El objeto proxy traduce las llamadas a los mtodos en mensajes XML/SOAP que son enviados al servicio Web. Del mismo modo, las respuestas generadas por este sern convertidas por el objeto proxy al tipo correspondiente .NET, a fin de que puedan ser manipuladas por la aplicacin. Uno de los puntos clave de .NET es que la clase proxy se genera a partir del documento WSDL que describe al servicio Web, es decir, es independiente de la naturaleza e implementacin de este, lo que permite crear aplicaciones .NET capaces de consumir servicios Web de diferentes fabricantes que se estn ejecutando en plataformas diversas.

Captulo 5. Programacin de Servicios Web

Pgina 15

Creacin de la aplicacin cliente De lo explicado anteriormente se deduce que la fase ms importante en el proceso de creacin de una aplicacin cliente de un servicio Web ser la generacin de la clase proxy. A partir de ese momento, el desarrollo de la aplicacin no difiere en absoluto del de cualquier aplicacin estndar .NET. Visual Studio.NET permite crear una clase proxy para todos los tipos de proyecto (Consola, Windows o ASP.NET), lo que significa que cualquier aplicacin .NET puede ser cliente de un servicio Web. Como ejemplo, vamos a crear una aplicacin ASP.NET consistente en una nica pgina aspx, en la que se solicitar al usuario la introduccin de una cadena de caracteres a travs de un TextBox. Al pulsar el botn "Calcular", se le indicar en un control Label el nmero de caracteres de la cadena introducida, haciendo uso del servicio Web de ejemplo creado anteriormente. Una vez diseada la interfaz grfica de la aplicacin cliente, procederemos a la creacin de la clase proxy. Para ello, nos situaremos sobre el proyecto en el explorador de soluciones y en el men contextual que aparece al pulsar el botn derecho del ratn elegiremos la opcin Aadir Referencia Web. Aparecer entonces un cuadro de dilogo en el que se nos solicita la introduccin de la URL correspondiente al documento WSDL que describe el servicio Web que queremos utilizar. Este es el nico dato que necesita Visual Studio.NET para crear la clase proxy, ya que en este documento estn descritos los mtodos que expone el servicio, los parmetros de entrada de cada uno, los tipos de devolucin y su localizacin. Ver imagen:

Captulo 5. Programacin de Servicios Web

Pgina 16

En la Url podemos copiarla directamente de la ejecucin del servicio web en el navegador. Slo hay que aadirle al final de la Url, ?WSDL. Despus de introducir la URL del documento WSDL asociado al servicio Web de ejemplo, pulsaremos el botn "Ir", apareciendo entonces en la parte inferior del cuadro de dilogo la lista de mtodos expuestos por este (Ver pantalla). En la caja de texto "Nombre de Referencia Web" indicaremos el nombre del espacio de nombres en el que se crear la clase proxy; por defecto aparece el nombre del servidor donde est publicado, que en nuestro caso es "localhost" en referencia a la propia mquina local. Al pulsar el botn Agregar Referencia se producir la generacin automtica de la clase proxy, aadindose una referencia a la misma dentro del proyecto actual. En el explorador de soluciones podemos ver entonces que aparece una nueva carpeta dentro del proyecto, llamada App_WebReferences, dentro de la cual se encuentra la clase proxy generada. El nombre de esta clase ser el mismo que se asign al servicio Web (por defecto, el nombre del archivo .asmx). A partir de aqu, invocar a los mtodos del servicio Web se convertir en una tarea idntica a la invocacin de un mtodo de cualquier clase: declararemos el espacio de nombres donde se encuentra la clase proxy, crearemos una instancia de la misma e invocaremos a sus mtodos. En nuestra aplicacin de ejemplo, el cdigo de utilizacin de la clase proxy lo incluiremos en el mtodo de respuesta al evento Click del botn:
protected void btnAceptar_Click(object sender, EventArgs e) { Service objServicio = new Service(); lblTexto.Text = "El nmero de caracteres es: " + objServicio.LongitudCadena(tbxTexto.Text).ToString(); }

La clase Service es la clase proxy que se ha creado. En nuestro ejemplo, cuando nos pregunt el Agregar Referencia, sino cambiamos el nombre de localhost, deberemos de hacer un using localhost, si queremos acceder a la clase Service.

Ejercicio 1. Desarrollar un servicio Web que devuelva un DataTable con los resultados de una consulta sobre la base de datos Empresa. A continuacin implementar el servicio en Windows y en una aplicacin Web.

Captulo 5. Programacin de Servicios Web

Pgina 17

(Pgina Final Documento)

Captulo 5. Programacin de Servicios Web

Pgina 18