Los servicios Web de ASP.NET soportan
tres protocolos:
Pero quiero remarcar que en producción
se utilizará siempre el protocolo SOAP, ya que los dos restantes se consideran
solamente protocolos auxiliares que permiten realizar pruebas sobre el
Servicio Web ya sea a través del explorador o de aplicaciones ASP
antiguas.
Examinemos en detalle donde
podemos habilitar cada uno de estos protocolos, las solicitudes y respuestas
que se efectúan en cada caso y las implicancias de ello.
El establecimiento de los protocolos
lo podemos realizar en el archivo “machine.config” para el entorno del equipo
o bien en el ámbito del archivo “web.config” donde estamos realizando
puntualmente sobre el servicio.
Como muestra la siguiente figura en el ámbito del archivo
“web.config” podemos realizar un Add o un Remove que posteriormente veremos en
detalle.
De esta manera tendríamos habilitados los tres protocolos
en nuestro servicio Web, pero para realizar las pruebas vamos a crear un
Servicio Web de ejemplo que realice la lógica de recibir un entero como
parámetro y realice un cálculo, en este caso solamente a modo de prueba le
suma el numero 25 y devuelve este valor
Creamos un nuevo proyecto en Visual
Studio, en mi caso un Web Service de Visual Basic.
En mi caso particular nombré al proyecto como
“AccesoDatosWsVb” y al “Web Service” lo nombré “Datos” como vemos en la
siguiente figura.
Veamos el código del simple servicio Web
planteado
Muy simple y a manera de ejemplo, ya
que tenemos que saber que debemos realizar controles sobre parámetros y
tipos
Bien, una vez que tenemos nuestro servicio Web listo
vamos a proceder a probarlo en forma local para asegurarnos su
funcionamiento
En este
punto nuestro servicio Web “Datos”, el método “Calcular”, el parámetro que
solicitado y el botón de invocar para llamar al método como indican en la
figura cada una de la flechas.
Hasta este punto está todo claro y
sencillo, además esta pantalla nos muestra los protocolos habilitados para
nuestro servicio con las solicitudes y respuestas de cada uno. En este punto es
donde nos vamos a detener para asegurar t examinar nuestro servicio Web.
En primer punto les voy a mostrar los datos básicos de
solicitud de cada uno.
HTTP GET
Me ineteresa mostrar lo que propone Visual Studio
textualmente en la pagina de prueba del Web Service, esto lo apreciamos en las
siguientes lineas.
HTTP GET
A continuación se muestra un ejemplo
de solicitud y respuesta para HTTP GET. Es necesario reemplazar los marcadores
de posición que aparecen con valores reales.
GET
/AccesoDatosWsVB/Datos.asmx/Calcular?numero1=string HTTP/1.1
Host: localhost
HTTP/1.1
200 OK
Content-Type: text/xml; charset=utf-8
Content-Length: length
<?xml
version="1.0" encoding="utf-8"?>
<int
xmlns="http://nico.local/AccesoDatosWsVB/Datos">int</int>
El protocolo “HTTP GET” impide que se
pasen estructuras y objetos como argumentos, tampoco permite pasar argumentos
por referencia, aunque es legal devolver un objeto.
La misma lógica ocurre para el
protocolo “HTTP POST”.
Para verificar un consulta GET he
decidido armar una aplicación Windows forms que podría ser tranquilamente una
aplicación vb6 ya que voy a utilizar un COM MSXML.
Bien, creamos una aplicación “Windows Forms” de visual
Basic en mi caso colocamos un par de controles como indica la figura del modo
diseño del proyecto
Solo tenemos que tener en cuenta
agregar la referencia al objeto MSXML, como vemos en la siguiente figura.
Yo utilizo en este ejemplo la versión
3.0
Una vez que tengamos la referencia
realizada veamos el código de llamada al servicio Web.
Bien ahora les voy a explicar un poco mas este sencillo
código.
Private Sub btnEnviar_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles btnEnviarGet.Click
'Esta url permite realizar la llamada
GET pongan atención a que los parámetros viajan en la
url
Dim url As String =
"http://10.0.0.1/AccesoDatosWsVB/Datos.asmx/" & "Calcular?numero1="
'Instancio el objeto MSXML
Dim httpRequest As New MSXML2.XMLHTTP30
'Realizo un open, pasando el verbo GET en este caso, ela
url y le concateno_
'El numero del textbox que tengo en mi formulario
httpRequest.open("GET", url &
CStr(Trim(txtNumero.Text)), False)
'Realizo el envio de los datos
httpRequest.send()
'Creo un objeto document para
almacenar la respuesta
Dim xml As MSXML2.DOMDocument30
xml = httpRequest.responseXML
'Encierro en un bloque de control mi metodo de muestra
Try
'Muestro el resultado mediante un mensaje
MessageBox.Show("El
resultado " & xml.documentElement.text)
Catch ex As Exception
MessageBox.Show("Ha
ocurrido un error el protocolo puede no estar habilitado")
End Try
End Sub
Veamos el gráfico del entorno de prueba
planteado.
Antes de realizar la
prueba, en nuestro servicio Web tenemos los tres protocolos habilitados, voy a
configurar que solamente esté habilitado el “HTTP GET”.
Veamos a este punto, que
muestra la página de prueba del servicio Web.
Como vemos solo está
habilitado el protocolo “HTTP GET”
En este punto estamos en
condiciones de ejecutar nuestra aplicación de ejemplo para ver si es posible
acceder a los datos del servicio Web a través de “HTTP GET”.
Como vemos el resultado,
es correcto pero veamos que indica nuestro
sniffer.
La transacción tiene como resultado 3 paquetes con un
peso de 567 bytes pero analicemos en profundidad si es que es correlativo con
nuestra hipótesis teórica planteada en cuanto al formato de la solicitud y
respuesta.
Como podemos apreciar es
totalmente correcta nuestra hipótesis planteada ya que como muestran los datos
encerrados en los círculos la solicitud y la respuesta se correlaciona con la
teoría presentada.
Para finalizar las pruebas con “HTTP GET” voy a
deshabilitar el protocolo en el servicio Web y a realizar la solicitud con la
aplicación de prueba nuevamente, en este caso no va devolver datos.
Veamos el resultado de la aplicación
Y efectivamente ya no
podemos realizar más solicitudes “HTTP GET”
Pero veamos que dice
nuestro sniffer del error generado.
Y vemos el error de
manera detallada ya que está habilitado el detalle.
Con este terminamos
nuestras pruebas de interoperatividad con “HTTP GET”.
HTTP POST
De la misma manera que
realizamos las pruebas con el GET voy a plantear el entorno de pruebas para el
POST.
A la aplicación que
realizamos en Windows Forms le voy a agregar un nuevo boton donde voy a
generar código para conectarme al servicio Web mediante un “HTTP POST”.
Veamos la aplicación y
el código utilizado.
Ante todo el diseño quedaría de esta
manera.
Veamos el código
programado para la solicitud en el botón POST.
Existen algunas
diferencias con respecto al código del GET ya que en este caso los parámetros
no van en la url sino en el cuerpo http.
Ahora voy a habilitar en el
servicio Web solamente el protocolo “HTTP POST” para realizar la
prueba.
Bien en este punto voy a realizar la solicitud con la
aplicación de prueba.
De hecho funciona de manera perfecta, pero lo interesante
lo muestra nuestro sniffer con lo cual verificaremos el mecanismo de solicitud
respuesta
Bien como podemos
observar, de manera perfecta se realiza el POST con una carga de 794 bytes, lo
muestran los datos encerrados en el primero de los círculos, luego se pasa el
parámetro donde lo indica la flecha y por ultimo la misma respuesta como lo
indican los datos encerrados en el segundo de los círculos.
Según la teoría esto debería ser como lo muestra la
siguiente captura.
Y la correlación es completa, nuevamente vemos que
obtenemos en la práctica valores coherentes
Para finalizar con el protocolo POST voy a
deshabilitar en el servicio Web ambos “HTTP GET” y “HTTP POST” como debe ser
en producción para solamente conectarme mediante SOAP, y vos a probar realizar
la solicitud que fallará sin ninguna duda.
Dejo solamente SOAP
habilitado en el servicio Web.
Como ven efectivamente
genera un error ya que solamente puedo realizar solicitudes mediante SOAP.
Veamos que dice el sniffer sobre esta negativa al
POST
Bien de la misma manera
que en el GET se genera el detalle del error.
Resumen
Hemos realizado un
pequeño y simple servicio Web el cual lo hemos consultado mediante los
protocolos “http GET” y “http POST” habilitando y deshabilitando este
mecanismo en casa ámbito de prueba para verificar el funcionamiento correcto
de las solicitudes en cada caso.
Esto nos permite
comprender el funcionamiento interno en cada caso de las solicitudes y
respuestas para poder interoperar nuestros sistemas actuales o nuevos
desarrollos con servicios Web de diversas maneras.
Mi objetivo es realizar
el primer paso mostrando estos dos protocolos para luego profundizar en un
articulo siguiente sobre SOAP, armar un sistemas de capa de negocio que
consulte de mane ra segura nuestro servicio Web y habilitar esta capa para
consultas a través de una aplicación mobile.
Hasta la próxima.
Plataforma utilizada
- Visual Studio 2003
- Ethereal
Desarrollador
Nicolás Bortolotti
Estudiante de Ing. en sistemas de
información
de la
Universidad Tecnológica Nacional San
Francisco- Provincia de Córdoba.
