Colaboraciones en el Guille

Inside Web Services - Fase 1

Protocolos de servicios Web 

 

Fecha: 04/Ene/2006 (03-01-06)
Autor: Nicolas Bortolotti - [email protected]


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.

configuracion de Web Config para habilitar todos los protocolos

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.

 proyecto de Web Services

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

pagina de prueba del web service

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

aplicación Windows Forms para prueba de Protocolo

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

para agregar referencia dl componente MSXML

Una vez que tengamos la referencia realizada veamos el código de llamada al servicio Web.

código del boton enviar de la aplicación Windows Forms

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.

gráfico de escenario 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”.

habilitado solo el protocolo GET

Veamos a este punto, que muestra la página de prueba del servicio Web.

página de prueba mostrando solo los protocolos habilitados

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”.

funcionamiento de la aplicacion windows forms consultando el Web Service con GET

Como vemos el resultado, es correcto pero veamos que indica nuestro sniffer.

resultado mostrado por el sniffer en la captura de paquetes.

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.

detalle de las tramas en la consulta GET

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.

deshabilitados todos los protocolos

Veamos el resultado de la aplicación

error generado al correr la consulta GET

Y efectivamente ya no podemos realizar más solicitudes “HTTP GET”

 Pero veamos que dice nuestro sniffer del error generado.

Verificación de las tramas en la generacion del error

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.

Habilitamos nuestra aplicacion Windows Forms para el protocolo POST

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.

configuración solo del protocolo POST para el web Service

Bien en este punto voy a realizar la solicitud con la aplicación de prueba.

ejecutamos una consulta POST con nuestro Web Service

De hecho funciona de manera perfecta, pero lo interesante lo muestra nuestro sniffer con lo cual verificaremos el mecanismo de solicitud respuesta

vemos el detalle del sniffer para la consulta POST

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.

Configuracion propuesta por visual Studio para consultas POST

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.

solo habilitado SOAP

Dejo solamente SOAP habilitado en el servicio Web.

Fallo de la consulta POST

Como ven efectivamente genera un error ya que solamente puedo realizar solicitudes mediante SOAP.

 Veamos que dice el sniffer sobre esta negativa al POST

Verificacion de las tramas de error de la consulta 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  

  1. Visual Studio 2003
  2. 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.

Mi imagen


ir al índice principal del Guille