Sie sind auf Seite 1von 25

5 Servicios Web XML.

5.1 Visión general de servicios Web XML.


5.2 Tecnologías subyacentes.
5.2.1 SOAP
5.2.2 WSDL
5.2.3 UDDI
5.3 Publicación de un servicio WEB.
5.4 Consumo de un servicio WEB.

5.1 Visión general de servicios Web XML.


Los servicios Web XML son un conjunto de aplicaciones o de tecnologías con capacidad para
interoperar en la Web. Estas aplicaciones o tecnologías intercambian datos entre sí con el
objetivo de ofrecer unos servicios. Los proveedores ofrecen sus servicios como procedimientos
remotos y los usuarios solicitan un servicio llamando a estos procedimientos a través de la
Web, por lo que estos servicios deben estar alojados en un servidor Web. Los servicios Web
XML permiten el manejo distribuido de componentes, estos permiten tomar ventaja de la
infraestructura de Internet para la distribución de funcionalidad y paquetes de datos.
Las principales características de los servicios Web XML son:
Están basados en protocolos estándar para la Web. Los servicios Web XML realizan
las peticiones y proporcionan las respuestas utilizando protocolos estándar de la Web,
como los son HTTP (Hyper Text Transfer Protocol), XML (Extensible Markup
Language), y SOAP (Simple Object Access Protocol), toda plataforma que maneje
dichos protocolos, podrá aprovechar la funcionalidad de los servicios Web XML.
Comunicación de aplicación a aplicación basada en Internet. Al utilizar un servicio Web
XML no se tienen una interfaz de usuario visible; realmente se trata de un componente
que puede ser consumido de manera programática de aplicación a aplicación. Los
servicios Web XML proporcionan una interfaz estándar para la recepción de peticiones
y envío de respuesta, denominada contrato, dicho contrato pone a disposición de los
usuarios la información requerida por el componente, describe los comportamientos del
mismo, y relaciona los datos de entrada con la salida del componete.
Independencia del lenguaje. Los servicios Web XML pueden ser consumidos desde
programas escritos en cualquier lenguaje .NET, por lo cual no es necesario aprender
un lenguaje determinado para poder tener acceso a su funcionalidad.
Independencia de la plataforma. Independientemente de la plataforma que dispongan
los clientes de una aplicación, el contrato se encarga de hacer la petición en un formato
estándar, y de recibir la respuesta correspondiente.
Arquitectura libre del manejo de estados (stateless architecture). Los servicios Web
XML no manejan estados de objetos; cada respuesta brindada por un servicio Web
XML es una nueva instancia de un objeto, con su estado particular. Lo que una petición
realiza no impacta lo realizado por otras peticiones.
Comunicación síncrona y asíncrona. El requerimiento de ejecución de un método de
servicio Web XML, y el requerimiento de la respuesta, son independientes. La
aplicación que consume el servicio Web XML, y el servicio Web XML mismo, pueden
operar con mayor disponibilidad, ya que liberan recursos mientras se está en tiempo de
espera.
Las aplicaciones intercambian datos entre sí en un medio ambiente seguro usando
XML signature y XML encryption, XML signature ofrece servicios de integridad y
autenticación de mensajes para los datos, XML encryption es el proceso para codificar
datos de tal manera que usuarios no autenticados no puedan entenderlos.

Los principales usos que tienen los servicios Web XML son los siguientes:
Cuando se requiere compartir funcionalidad libre de interfaz de usuario. Los servicios
Web son útiles en cuando se desea consumir la funcionalidad de un componente, sin la
intermediación de una interfaz de usuario. Ejemplos de esto es el consumo de servicios
que proporcionan información, como tipos de cambio, estado del clima, precios de
productos, disponibilidad de lugares en eventos, sin tener que responder a alguna
interfaz de usuario.
Cuando se quiere comercializar un servicio de uso de software, y no un producto de
software. En el futuro, no se venderá software, sino la funcionalidad que el software
brinda estará disponible como servicio en la Web.
Cuando el equipo cliente y servidor requieren compartir funcionalidad en Internet, pero
difieren en su plataforma operativa.

5.2 Tecnologías subyacentes.


Las especificaciones que se han desarrollado para implementar los servicios Web se presentan
como una pila de tecnologías donde las especificaciones superiores hacen uso de las
inferiores, como se muestra en la figura 5.1.

Figura 5.1

5.2.1 SOAP (Simple Object Access Protocol).


Para ser capaces de comunicarse entre sí, un servicio Web y una aplicación cliente deben
concordar sobre un protocolo común. SOAP es un protocolo estándar de comunicación para
intercambiar información en un formato estructurado en un medio ambiente distribuido. La
información intercambiada entre la aplicación cliente y el servicio Web es llamado mensaje. Los
mensajes incluyen las llamadas hechas por una aplicación cliente a un método Web y los datos
retornados por el método Web al cliente. Cuando una aplicación cliente hace una solicitud a un
método Web, un paquete SOAP es creado. Este paquete contiene el nombre del método Web
invocado y los parámetros pasados al método Web en un formato XML. Esta información es
usada para invocar el método Web con los parámetros apropiados. Cuando el paquete SOAP
llega al servidor Web en el cual reside el servicio Web, el nombre del método Web y sus
parámetros son extraídos del paquete SOAP y el método Web apropiado es invocado.

SOAP especifica lo siguiente:


Un formato de mensaje para una comunicación unidireccional, describiendo cómo se
empaqueta la información en documentos XML.
Un conjunto de convenciones para usar mensajes SOAP para implementar el patrón de
interacción RPC (Remote Procedure Call), definiendo cómo los clientes pueden invocar
un Procedimiento Remoto enviando un mensaje SOAP y cómo los servicios pueden
responder enviando otro mensaje al llamador.
Un conjunto de reglas que una entidad que procesa mensajes SOAP debe seguir,
definiendo en particular los elementos XML que una entidad debe leer y entender, así
como las acciones que deben tomar si no entienden el contenido, estas reglas son
llamadas: Reglas de Codificación de los Datos.
Una descripción de cómo se debe transportar un mensaje SOAP sobre HTTP y SMTP.

Cada mensaje contiene los siguientes elementos:


Elemento envelope, este es el elemento raíz de un documento SOAP, este elemento
contiene los elementos header y body del mensaje SOAP, este elemento es obligatorio.
Elemento header, este elemento es opcional y da al servidor información extra, como
autenticación y manejo de transacciones.
Elemento body, este elemento es obligatorio que contiene datos concretos del mensaje
SOAP, este elemento contiene información tal como nombre del método, parámetros, y
los valores en la invocación del método.
Elemento fault, este elemento es utilizado para determinar si existe algún error en el
mensaje SOAP y no desplegar mensajes de error.

La cabecera y el cuerpo pueden tener múltiples subpartes en forma de bloques de la cabecera


y bloques del cuerpo.

Cuando una aplicación cliente hace una solicitud a un método Web, un paquete SOAP es
creado. Este paquete contiene el nombre del método Web que es invocado, y los parámetros
que son pasados al método Web en un formato XML. Cuando el paquete SOAP llega al
servidor Web en el cual reside el servicio Web, el método Web y sus parámetros son extraídos
del paquete SOAP y el método es invocado.

Este son unos ejemplos de una solicitud SOAP.

En esta liga se puede revisar un servicio Web que proporciona información del clima
http://www.webservicex.net/globalweather.asmx?op=GetWeather

Esta es la solicitud del servicio de clima:

<?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>
<GetWeather xmlns="http://www.webserviceX.NET">
<CityName>string</CityName>
<CountryName>string</CountryName>
</GetWeather>
</soap:Body>
</soap:Envelope>

Esta es la respuesta del servicio de clima:

<?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>
<GetWeatherResponse xmlns="http://www.webserviceX.NET">
<GetWeatherResult>string</GetWeatherResult>
</GetWeatherResponse>
</soap:Body>
</soap:Envelope>

5.2.2 WSDL (Web Services Description Language). El Lenguaje de


Descripción.
WSDL es un lenguaje estándar basado en XML, que define como los servicios Web XML son
descritos cuando son publicados en un registro. La información del servicio Web XML es
publicada en registros como documentos WSDL. El documento WSDL es un archivo XML que
incluye el esquema de interfaz del servicio Web XML. WSDL reconoce los métodos que son
intercambiados entre el proveedor del servicio Web XML y el consumidor del servicio Web
XML. Un documento WSDL proporciona información a los clientes de cómo acceder a los
servicios Web XML. WSDL proporciona la información usando varios elementos. Estos
elementos de un archivo WSDL incluyen lo siguiente:
Types. Define los tipos de datos utilizados para el intercambio de mensajes entre el
consumidor y el servicio.
Message. Describe los mensajes que serán comunicados entre el consumidor y el
servicio.
portType. Identifica el conjunto de operaciones que realiza el servicio, y los mensajes
involucrados en dichas operaciones.
Binding. Específica los detalles de protocolo para el intercambio de mensajes entre las
operaciones, describiendo cómo traducir contenido abstracto a un formato estándar.
Service. Agrupa aquellos puertos que estén relacionados, y que implementan un
servicio Web.

Para poder ver un documento WSDL utilizamos el mismo servicio de clima utilizado
anteriormente y lo invocamos agregándole ?WSDL al final del URL

http://www.webservicex.net/globalweather.asmx?WSDL

El documento WSDL obtenido es el siguiente:

<?xml version="1.0" encoding="utf-8" ?>


<wsdl:definitions xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:s="http://www.w3.org/2001/XMLSchema"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:tns="http://www.webserviceX.NET"
xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/"
xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"
targetNamespace="http://www.webserviceX.NET"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">
<wsdl:types>
<s:schema elementFormDefault="qualified"
targetNamespace="http://www.webserviceX.NET">
<s:element name="GetWeather">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="CityName" type="s:string"
/>
<s:element minOccurs="0" maxOccurs="1" name="CountryName"
type="s:string" />
</s:sequence>
</s:complexType>
</s:element>
<s:element name="GetWeatherResponse">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="GetWeatherResult"
type="s:string" />
</s:sequence>
</s:complexType>
</s:element>
<s:element name="GetCitiesByCountry">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="CountryName"
type="s:string" />
</s:sequence>
</s:complexType>
</s:element>
<s:element name="GetCitiesByCountryResponse">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="GetCitiesByCountryResult"
type="s:string" />
</s:sequence>
</s:complexType>
</s:element>
<s:element name="string" nillable="true" type="s:string" />
</s:schema>
</wsdl:types>
<wsdl:message name="GetWeatherSoapIn">
<wsdl:part name="parameters" element="tns:GetWeather" />
</wsdl:message>
<wsdl:message name="GetWeatherSoapOut">
<wsdl:part name="parameters" element="tns:GetWeatherResponse" />
</wsdl:message>
<wsdl:message name="GetCitiesByCountrySoapIn">
<wsdl:part name="parameters" element="tns:GetCitiesByCountry" />
</wsdl:message>
<wsdl:message name="GetCitiesByCountrySoapOut">
<wsdl:part name="parameters" element="tns:GetCitiesByCountryResponse"
/>
</wsdl:message>
<wsdl:message name="GetWeatherHttpGetIn">
<wsdl:part name="CityName" type="s:string" />
<wsdl:part name="CountryName" type="s:string" />
</wsdl:message>
<wsdl:message name="GetWeatherHttpGetOut">
<wsdl:part name="Body" element="tns:string" />
</wsdl:message>
<wsdl:message name="GetCitiesByCountryHttpGetIn">
<wsdl:part name="CountryName" type="s:string" />
</wsdl:message>
<wsdl:message name="GetCitiesByCountryHttpGetOut">
<wsdl:part name="Body" element="tns:string" />
</wsdl:message>
<wsdl:message name="GetWeatherHttpPostIn">
<wsdl:part name="CityName" type="s:string" />
<wsdl:part name="CountryName" type="s:string" />
</wsdl:message>
<wsdl:message name="GetWeatherHttpPostOut">
<wsdl:part name="Body" element="tns:string" />
</wsdl:message>
<wsdl:message name="GetCitiesByCountryHttpPostIn">
<wsdl:part name="CountryName" type="s:string" />
</wsdl:message>
<wsdl:message name="GetCitiesByCountryHttpPostOut">
<wsdl:part name="Body" element="tns:string" />
</wsdl:message>
<wsdl:portType name="GlobalWeatherSoap">
<wsdl:operation name="GetWeather">
<documentation xmlns="http://schemas.xmlsoap.org/wsdl/">Get weather
report for all major cities around the world.</documentation>
<wsdl:input message="tns:GetWeatherSoapIn" />
<wsdl:output message="tns:GetWeatherSoapOut" />
</wsdl:operation>
<wsdl:operation name="GetCitiesByCountry">
<documentation xmlns="http://schemas.xmlsoap.org/wsdl/">Get all major
cities by country name(full / part).</documentation>
<wsdl:input message="tns:GetCitiesByCountrySoapIn" />
<wsdl:output message="tns:GetCitiesByCountrySoapOut" />
</wsdl:operation>
</wsdl:portType>
<wsdl:portType name="GlobalWeatherHttpGet">
<wsdl:operation name="GetWeather">
<documentation xmlns="http://schemas.xmlsoap.org/wsdl/">Get weather
report for all major cities around the world.</documentation>
<wsdl:input message="tns:GetWeatherHttpGetIn" />
<wsdl:output message="tns:GetWeatherHttpGetOut" />
</wsdl:operation>
<wsdl:operation name="GetCitiesByCountry">
<documentation xmlns="http://schemas.xmlsoap.org/wsdl/">Get all major
cities by country name(full / part).</documentation>
<wsdl:input message="tns:GetCitiesByCountryHttpGetIn" />
<wsdl:output message="tns:GetCitiesByCountryHttpGetOut" />
</wsdl:operation>
</wsdl:portType>
<wsdl:portType name="GlobalWeatherHttpPost">
<wsdl:operation name="GetWeather">
<documentation xmlns="http://schemas.xmlsoap.org/wsdl/">Get weather
report for all major cities around the world.</documentation>
<wsdl:input message="tns:GetWeatherHttpPostIn" />
<wsdl:output message="tns:GetWeatherHttpPostOut" />
</wsdl:operation>
<wsdl:operation name="GetCitiesByCountry">
<documentation xmlns="http://schemas.xmlsoap.org/wsdl/">Get all major
cities by country name(full / part).</documentation>
<wsdl:input message="tns:GetCitiesByCountryHttpPostIn" />
<wsdl:output message="tns:GetCitiesByCountryHttpPostOut" />
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="GlobalWeatherSoap" type="tns:GlobalWeatherSoap">
<soap:binding transport="http://schemas.xmlsoap.org/soap/http"
style="document" />
<wsdl:operation name="GetWeather">
<soap:operation soapAction="http://www.webserviceX.NET/GetWeather"
style="document" />
<wsdl:input>
<soap:body use="literal" />
</wsdl:input>
<wsdl:output>
<soap:body use="literal" />
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="GetCitiesByCountry">
<soap:operation
soapAction="http://www.webserviceX.NET/GetCitiesByCountry"
style="document" />
<wsdl:input>
<soap:body use="literal" />
</wsdl:input>
<wsdl:output>
<soap:body use="literal" />
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:binding name="GlobalWeatherHttpGet"
type="tns:GlobalWeatherHttpGet">
<http:binding verb="GET" />
<wsdl:operation name="GetWeather">
<http:operation location="/GetWeather" />
<wsdl:input>
<http:urlEncoded />
</wsdl:input>
<wsdl:output>
<mime:mimeXml part="Body" />
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="GetCitiesByCountry">
<http:operation location="/GetCitiesByCountry" />
<wsdl:input>
<http:urlEncoded />
</wsdl:input>
<wsdl:output>
<mime:mimeXml part="Body" />
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:binding name="GlobalWeatherHttpPost"
type="tns:GlobalWeatherHttpPost">
<http:binding verb="POST" />
<wsdl:operation name="GetWeather">
<http:operation location="/GetWeather" />
<wsdl:input>
<mime:content type="application/x-www-form-urlencoded" />
</wsdl:input>
<wsdl:output>
<mime:mimeXml part="Body" />
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="GetCitiesByCountry">
<http:operation location="/GetCitiesByCountry" />
<wsdl:input>
<mime:content type="application/x-www-form-urlencoded" />
</wsdl:input>
<wsdl:output>
<mime:mimeXml part="Body" />
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="GlobalWeather">
<wsdl:port name="GlobalWeatherSoap" binding="tns:GlobalWeatherSoap">
<soap:address location="http://www.webservicex.net/globalweather.asmx"
/>
</wsdl:port>
<wsdl:port name="GlobalWeatherHttpGet"
binding="tns:GlobalWeatherHttpGet">
<http:address location="http://www.webservicex.net/globalweather.asmx"
/>
</wsdl:port>
<wsdl:port name="GlobalWeatherHttpPost"
binding="tns:GlobalWeatherHttpPost">
<http:address location="http://www.webservicex.net/globalweather.asmx"
/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>

Este documento muestra los elementos de un documento WSDL, especificando los tipos,
mensajes, operaciones y enlaces que ofrece este servicio Web.

5.2.3 UDDI (Universal Description, Discovery, and Integration). El


Repositorio de Servicios.
Uno de los puntos más importantes de un servicio es su publicidad, pensando en ello, se ha
definido un mecanismo para darles publicidad a los servicios Web XML que las empresas
desarrollan, denominado UDDI.
Cuando un proveedor de servicios Web quiere poner un servicio Web disponible para clientes
de aplicación, el proveedor describe el servicio Web usando un documento WSDL. Entonces el
proveedor registra el servicio Web en el directorio UDDI. El directorio UDDI contiene
apuntadores a el servicio Web y el documento WSDL de el servicio Web. De esta manera las
aplicaciones Cliente pueden descubrir el servicio Web usando el directorio UDDI.
La especificación UDDI tiene dos objetivos esenciales: (1) ser un soporte a los desarrolladores
para encontrar información sobre servicios web y poder construir clientes, (2) facilitar el Enlace
Dinámico de Servicios Web, permitiendo consultar referencias y acceder a servicios de interés.

La información en un registro UDDI se almacena en archivos XML con una estructura


jerárquica, Los elementos de esta estructura son:
businessEntity: Describe la organización que ofrece el servicio (Nombre, dirección, etc.)
businessService: Grupo de servicios Web relacionados ofrecido por una BusinessEntity
(empresa), pero ofrecida en diferentes direcciones, versiones, y tecnologías. Al igual
que las BusinessEntity, pueden incluir información de clasificación.
bindingTemplate: Información técnica para utilizar el servicio, (Dirección del servicio,
Referencias documentos (tModels) describiendo la interfaz u otras propiedades, Como
dar valor a los parámetros y valores por defecto).
tModel: (Technology Model). Estructura de Metadatos Genérica para representar
cualquier concepto o construcción (definiciones de protocolos, ficheros WSDL, XML
schemas, Espacios de Nombres, esquemas de categorías, etc.).

La figura 5.2 muestra un ejemplo de cómo están estructurados los datos en un registro UDDI.
Figura 5.2

La figura 5.3 muestra la relación entre las tecnologías usadas para implementar un servicio
Web. La aplicación Cliente localiza un servicio Web XML mediante un Registro UDDI que
contiene apuntadores a los documentos WSDL y servicios Web XML, una vez localizado el
servicio Web XML la aplicación Cliente se comunica con el servicio Web mediante mensajes
SOAP.

Documento
Registro WSDL
UDDI

Localiza un
servicio Web

Aplicación Servicio Web


Cliente

Comunicación mediante Mensajes SOAP


Figura 5.3
5.3 Publicación de un servicio WEB.
Los servicios Web XML desde el punto de vista de programación, son muy parecidos a un
programa, mientras que en su consumo son más orientados al ambiente Web. Estos servicios
están constituidos por un archivo de extensión .asmx, y este archivo debe contener lo
siguiente:
1. La directiva @WebService. Esta directiva específica los atributos de servicio Web
XML. Esta directiva es el equivalente a @Page de las páginas Web. Los atributos que
utiliza esta directiva son:
Class. Específica la clase implementada por el servicio Web XML, esta se
compila automáticamente la primera vez que se tiene acceso al servicio Web
XML, o después de que se operan cambios en él.
CodeBehind. Específica el archivo de código fuente que contiene la clase
utilizada por el servicio Web XML.
Language. Específica el lenguaje .NET utilizado para codificar la clase que
implementa el servicio Web XML.

La sintaxis de cómo utilizar la directiva @WebService y sus atributos es la


siguiente:
<%@ WebService Language="C#" CodeBehind="NombreArchivo"
Class="NombreClase" %>
La directive @WebService se deberá colocar al principio del código del servicio
Web XML.

2. Importar el espacio de nombres System.Web.Services. El espacio de nombres


System.Web.Services es el espacio de nombres que contiene las clases que permiten
crear servicios Web XML, tales como WebService y WebMethodAttribute. La sintaxis
para importar el espacio de nombres es la siguiente.
using System.Web.Services;

Después de importar el espacio de nombres, se puede escribir el código de la clase


que constituirá el servicio Web; esta clase deberá heredar la funcionalidad de
System.Web.Services.WebService.

3. Crear una clase, ya sea dentro de la página o en modo Code Behind. Después de
establecer las directivas y haber importado los espacios de nombres, se deberá
codificar una clase, que contendrá el bloque de código que constituye el servicio Web
XML. Debe ser una clase porque al consumir un servicio Web XML
programáticamente, es necesario manejar la funcionalidad en modo objeto y éstos no
son otra cosa que instancias de una clase. La clase debe tener suficientes permisos,
de preferencia ser pública, sobre todo si el servicio Web XML podrá ser consumido
desde Internet. La sintaxis que se utiliza para declarar una clase es la siguiente:
public class NombreClase : System.Web.Services.WebService {
WebMetodos
}

4. Declarar como [WebMethod()] las funciones del servicio Web XML. Las funciones
incluidas en la clase constituyen el comportamiento del servicio Web XML, en su
definición, las funciones se asemejan mucho a las funciones que conocemos en
programación. Su diferencia radica en que deben ser de acceso público, y que deben
estar habilitadas para ser acreditadas por clientes remotos a través de la Web,
agregándoles el atributo WebMethod(). La sintaxis para declarar un WebMethod es la
siguiente:
[WebMethod(Description="Descripción del método")]
public TipoFuncion NombreFuncion(Parametros){
return ValorRetorno
}

Para crear un servicio Web con la herramienta Microsoft Visual Web Developer 2005, el primer
paso es crear el servicio Web, en el menú principal de esta herramienta seleccionamos la
opción Archivo y el menú que aparece seleccionamos la opción Nuevo sitio Web como se
muestra en la figura 5.4.

Figura 5.4

Aparece una ventana donde vamos a crear el nuevo sitio Web que contendrá el servicio Web,
seleccionamos la plantilla correspondiente al Servicio Web ASP.NET y proporcionamos la ruta
física donde va a estar almacenado este sitio y el lenguaje que se va a utilizar, en este caso el
lenguaje que seleccionamos es C#, como se muestra en la figura 5.5

Figura 5.5
Una vez que creamos el sitio Web, agregamos un nuevo elemento como se muestra en la
figura 5.6, que será la clase que contenga la funcionalidad del servicio Web.

Figura 5.6

En seguida aparece una pantalla donde vamos a seleccionar la plantilla correspondiente al


servicio Web, y proporcionamos el nombre del archivo que contenga el servicio Web con
extensión asmx, como se muestra en la figura 5.7.
Figura 5.7

Modificamos el código del archivo Aritmetica.cs para que quede de la siguiente manera:

using System;
using System.Web;
using System.Collections;
using System.Web.Services;
using System.Web.Services.Protocols;

/// <summary>
/// Descripción breve de Aritmetica
/// </summary>
[WebService(Namespace = "http://tempuri.org/")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
public class Aritmetica : System.Web.Services.WebService {

public Aritmetica () {

[WebMethod(Description="Suma dos números enteros")]


public int Suma(int N1, int N2)
{
return (N1 + N2);
}

[WebMethod(Description="Multiplicacion dos números enteros")]


public int Multiplicacion(int N1, int N2)
{
return (N1 * N2);
}

[WebMethod(Description = "Division entre dos números enteros")]


public int Division(int N1, int N2)
{
return (N1 / N2);
}
}

Generamos el sitio Web como se muestra en la figura 5.8.

Figura 5.8

Una vez que se ha desarrollado el servicio Web, el siguiente paso es desplegar el servicio Web
en un servidor Web, como el IIS Internet Information Services, para que esté disponible para
usuarios o aplicaciones cliente, para esto seleccionamos la opción Stio Web del menú principal
y del menú que aparece seleccionamos la opción Copiar sitio Web como en la figura 5.9.
Figura 5.9

Posteriormente se indica el sitio donde se va a desplegar el servicio Web, ya sea en el servidor


local o en un servidor remoto, como en la figura 5.10.

Figura 5.10

Y por último se seleccionan los archivos que se van a copiar en el servidor web, como en la
figura 5.11.
Figura 5.11

Para probar que el servicio Web quedo desplegado en el servidor web abrimos el IIS (Internet
Information Services) en esta herramienta el servicio Web se debe mostrar como una carpeta
virtual Figura 5.12.

Figura 5.12

Para publicar el servicio Web en el registro UDDI y este pueda ser descubierto por algún cliente
existen varias herramientas, una de ellas viene integrada en Windows Server 2003, para poder
utilizar esta herramienta primero se deben instalar los servicios UDDI, esto lo podemos hacer
en la opción Agregar Componentes de Windows como se muestra en la figura 5.13.
Figura 5.13

Una vez instalados los servicios UDDI utilizamos la interface web de esta herramienta, en un
navegador de internet tecleamos la dirección http://localhost/uddi figura 5.14.

Figura 5.14

Antes de publicar el servicio Web en el registro UDDI es necesario dar de alta el proveedor del
servicio Web (businessEntity), esto en la ventana correspondiente, Figura 5.15, especificando
la información necesaria de dicho proveedor.
Figura 5.15

Para agregar un nuevo servicio Web se utiliza la pestaña Services y en la ventana


correspondiente Figura 5.16 se asigna el nombre y la descripción del servicio, dentro de esta
misma ventana en la pestaña Bindings se especifica la ubicación del servicio Web, así como la
descripción de dicho servicio (bindingTemplate).

Figura 5.16

El paso final es proveer información técnica, parámetros, etc del servicio Web (tModel), Figura
5.17.
Figura 5.17

Este tmodel creado se asocia con el servicio Web Figura 5.18 y de esta manera el servicio Web
es publicado.

Figura 5.18

5.4 Consumo de un servicio WEB.


Los servicios Web XML pueden ser consumidos de dos maneras, directamente desde un
navegador o desde una aplicación de forma programática.
Las diferencias entre estas dos formas son las siguientes:
Directamente desde el navegador. La petición se realiza vía HTTP al servidor, este
mostrará la página de hipertexto de descripción, que lista los métodos disponibles en
el servicio Web XML. En dicha página puede seleccionar algún método disponible,
interactuar con la interfaz proporcionando datos y recibir la respuesta del servicio Web
XML. La respuesta que se recibe está en XML
Desde una aplicación, programáticamente. Se debe establecer una referencia hacia el
servicio Web XML, dicha referencia es un objeto que es utilizado para comunicarse con
el servicio Web utilizando SOAP. La clase que se genera es una equivalencia de la
clase original del servicio Web XML, con la diferencia de que no contiene la lógica de la
aplicación, en lugar de eso, la clase contiene la lógica de clasificación y transporte de
datos. La clase permite a la aplicación que consume el servicio Web XML disponer de
una respuesta manejada a través de SOAP, que permite manejar objetos más
complejos que HTTP. Se deberá en el programa generar una instancia de la clase,
utilizar los métodos del servicio Web XML y recibir los datos de la aplicación.

Cuando se realiza el consumo desde el navegador, todo el proceso ocurre ahí mismo en el
navegador.
1. Se debe hacer una solicitud del servicio Web XML utilizando HTTP.
2. Aparecerá la página de descripción, que expone todos los métodos del servicio, figura
5.19.
3. Se selecciona un método del servicio.
4. Se proporcionan los datos que el método requiere, figura 5.20.
5. Se reciben los resultados del método en formato XML.

Figura 5.19
Figura 5.20

El protocolo HTTP es textual, y es incapaz de manejar objetos complejos. Como este tipo de
consumo del servicio Web XML se realiza utilizando el protocolo HTTP, la respuesta sólo
puede ofrecerse mediante XML, por lo que el resultado de esta llamada queda de la siguiente
manera:

<?xml version="1.0" encoding="utf-8" ?>


<int xmlns="http://tempuri.org/">1</int>

Para poder probar este servicio Web programatica se agrega una página a un proyecto web
desarrollado en Microsoft Visual Web Developer 2005 y se le llama ConsumeWS, a esta página
se le agrega tres controles de tipo Label llamados “ResultadoSuma”, “ResultadoMultiplicacion”,
“ResultadoDivision”, el código html quedaría de la siguiente manera:

<%@ Page Language="C#" AutoEventWireup="true"


CodeFile="ConsumeWS.aspx.cs" Inherits="ConsumeWS" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"


"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" >


<head runat="server">
<title>Página sin título</title>
</head>
<body>
<form id="form1" runat="server">
<div>
<asp:Label ID="ResultadoSuma" runat="server" />
<asp:Label ID="ResultadoMultiplicacion" runat="server" />
<asp:Label ID="ResultadoDivision" runat="server" />
</div>
</form>
</body>
</html>

Al Proyecto se le agrega una referencia web, Figura 5.21 que es el servicio Web creado
anteriormente, al cual se le denomina Aritmetica, esta referencia se importa dentro de la página
y en el evento Load de la página se crea una instancia de la clase Aritmetica y se ejecuta el
método Suma del servicio Web, el resultado se muestra en la etiqueta llamada
ResultadoSuma, el método Multiplicación se muestra en la etiqueta ResultadoMultiplicacion y el
método Division se muestra en la etiqueta ResultadoDivision.

Figura 5.21

El código subyacente quedaría de la siguiente manera:

using System;
using System.Data;
using System.Configuration;
using System.Collections;
using System.Web;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Web.UI.HtmlControls;
using Aritmetica;

public partial class ConsumeWS : System.Web.UI.Page


{
protected void Page_Load(object sender, EventArgs e)
{
Aritmetica.Aritmetica Consumidor = new
Aritmetica.Aritmetica();
ResultadoSuma.Text = Consumidor.Suma(20, 30).ToString();
ResultadoMultiplicacion.Text =
Consumidor.Multiplicacion(2,3).ToString();
ResultadoDivision.Text = Consumidor.Division(20,
2).ToString();

}
}
El resultado obtenido es el siguiente:

Otra manera de utilizar un servicio Web de manera programática es mediante una clase proxy,
el procedimiento general es el siguiente:
1. Se debe tener desarrollado un servicio Web XML(.asmx).
2. Se debe descubrir el servicio Web mediante la herramienta disco.exe
3. Se debe crear una clase para el servicio Web XML mediante la herramienta wsdl.exe.
4. Se debe compilar la clase como librería.
5. En el proyecto donde se va a consumir el servicio Web se debe agregar una referencia
a la librería creada.
6. En el código del programa que consume el servicio Web XML deberá crearse una
instancia de la clase.
7. Se deberá invocar el método del servicio Web XML a través de la instancia de la clase
que se ha instanciado.
8. Se utiliza el resultado retornado por el servicio.

Una vez que se tiene desarrollado el servicio Web el siguiente paso es descubrir dicho servicio,
se conoce como descubrimiento de servicio Web al proceso por medio del cual se localiza un
servicio Web y su descripción, de tal manera que esté disponible para los programas que
consumen estos servicios, la herramienta que se utiliza para descubrir los servicios Web se
llama disco.exe, su sintaxis es la siguiente.

Disco.exe URL_Servicio

Donde URL_Servicio es la dirección del servicio Web, una vez que se ejecute este programa
se van a generar archivos de extensión .wsdl y .disco.

Una vez que se ha descubierto el servicio Web, el siguiente paso es crear una clase que
contenga cada método del servicio Web, esta clase se va a generar con la herramienta
wsdl.exe, su sintaxis es la siguiente:
wsdl [options] {URL|path}

Existen varias opciones que podemos usar al invocar la utilería wsdl.exe:


/baseurl: baseurl, esta opción convierte la URL relativa dada en esta opción en la URL
dada en el documento WSDL
/d:[domain], nombre de dominio.
/l:[lenguaje], lenguaje que se va a utilizar para crear la clase proxy, por ejemplo CS
para C# o VB para Visual Basic.
/n:[espacio de nombres], menciona el espacio de nombres para el proxy creado.
/o:[archivo de salida], menciona el nombre del archivo en el cual se va a guardar el
código del proxy generado.
/protocol: protocolo, menciona el protocolo que se va a implementar, estos pueden ser
SOAP, Httpget o HttpPost.
/proxy: URL, menciona el URL del servidor proxy para utilizar solicitudes HTTP.

La ejecución de wsdl.exe producirá un programa generado en el lenguaje especificado, que


deberá ser compilado como librería para su uso programático. Dicho programa contendrá la
misma funcionalidad del servicio Web XML, con todas las especificaciones descriptivas, para
compilar este programa se va a utilizar el compilador del lenguaje que se va a utilizar (visual
basic, c sharp).

Para crear la clase proxy del servicio Web generado anteriormente, realizamos los tres pasos
antes mencionados:
Descubrimos el servicio Web:
disco.exe http://localhost/Aritmetica/Aritmetica.asmx
Generamos la clase con la herramienta wsdl.exe:
wsdl /l:cs /n:AritmeticaWS Aritmetica.wsdl.

Generamos la librería del servicio Web con el compilador csc.exe


csc /target:library /out:Aritmeticadll.dll Aritmetica.cs /r:System.dll
/r:System.web.Services.dll /r:System.XML.dll

Para poder probar la librería generada del servicio Web en forma programática se agrega una
página a un proyecto web desarrollado en Microsoft Visual Web Developer 2005 y se le llama
ConsumeWSdll, a esta página se le agrega tres controles de tipo Label llamados
“ResultadoSuma”, “ResultadoMultiplicacion”, “ResultadoDivision”, el código html quedaría de la
siguiente manera:

<%@ Page Language="C#" AutoEventWireup="true"


CodeFile="ConsumeWSdll.aspx.cs" Inherits="ConsumeWSdll" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"


"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" >


<head runat="server">
<title>Página sin título</title>
</head>
<body>
<form id="form1" runat="server">
<div>
<asp:Label ID="ResultadoSuma" runat="server" />
<asp:Label ID="ResultadoMultiplicacion" runat="server" />
<asp:Label ID="ResultadoDivision" runat="server" />
</div>
</form>
</body>
</html>

Agregamos una referencia al proyecto como se muestra en la figura 5.22.


Figura 5.22

Creamos una instancia de la clase generada y utilizamos sus métodos, el código subyacente
quedaría de la siguiente manera:

using System;
using System.Data;
using System.Configuration;
using System.Collections;
using System.Web;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Web.UI.HtmlControls;

public partial class ConsumeWSdll : System.Web.UI.Page


{
protected void Page_Load(object sender, EventArgs e)
{
AritmeticaWS.Aritmetica Servicio = new
AritmeticaWS.Aritmetica();
ResultadoSuma.Text = Servicio.Suma(5, 5).ToString();
ResultadoMultiplicacion.Text =
Servicio.Multiplicacion(5,5).ToString();
ResultadoDivision.Text = Servicio.Division(25,5).ToString();
}
}

El resultado obtenido es el siguiente:

Das könnte Ihnen auch gefallen