Características de los Web Services
¿Alguna vez pensó de que forma poder integrar aplicaciones creadas en lenguajes y plataformas diferentes a través de Internet o mismo en su propia Intranet basándose en estándares? Bien, si lo pensó o si no lo hizo, la
respuesta más apropiada a este paradigma son los llamados Web Services.
respuesta más apropiada a este paradigma son los llamados Web Services.
Esto quiere decir que un desarrollador puede incluir en sus sitios o soluciones sentencias, instrucciones que consuman Web Services de terceros o propios como por ejemplo aquellos que proporcionan los datos meteorológicos para una localidad determinada, o las cotizaciones de determinadas monedas, o la cartelera de películas, o calendarios y agenda de algún especialista médico, etc. Esto ya comienza a gustarme.
Ahora pensando un poco mas en forma comercial, ¿que pasaría si por ejemplo yo estuviera trabajando en mi procesador de texto en un idioma para el cual no tengo un corrector ortográfico ni sintáctico instalado (quizás no exista para instalar), pero deseo realizar mi revisión del documento a toda costa? Bien, perfectamente podría haber una opción en el menú de dicho procesador que de alguna forma ubique un Web Service en Internet que brinde esta funcionalidad y lo mas interesante aún para quien lo haya desarrollado es que puede solicitar al usuario que se subscriba para su uso. Como ven, todos ganan en esta transacción.
El ejemplo anterior esta mostrando una realidad de la que no podemos estar ajenos. Es un replanteo de la estrategia utilizada por los desarrolladores que ahora al realizar una aplicación no deben pensar únicamente en el lugar físico donde la misma va a ejecutarse sino en que esa aplicación deberá estar interconectada con otras computadoras corriendo otras aplicaciones quizás en otras plataformas y lenguajes pero usando protocolos y estándares universales.
El intercambio se intensificará muchísimo mas y quizás existan por ejemplo “proveedores de dominios de datos” como ser los países, de forma tal que la aplicación que yo realice en lugar de crear toda la lógica para manejar las tablas y el cargado de los datos para el concepto PAIS se limite a consumir un Web Service que me torne esta información de algún lado en Internet. Imagino una reutilización aun mayor de funcionalidades y una colaboración e intercambio de lógica a nivel mundial. Quizás sea muy ambicioso en este planteo.
El intercambio se intensificará muchísimo mas y quizás existan por ejemplo “proveedores de dominios de datos” como ser los países, de forma tal que la aplicación que yo realice en lugar de crear toda la lógica para manejar las tablas y el cargado de los datos para el concepto PAIS se limite a consumir un Web Service que me torne esta información de algún lado en Internet. Imagino una reutilización aun mayor de funcionalidades y una colaboración e intercambio de lógica a nivel mundial. Quizás sea muy ambicioso en este planteo.
Ahora pasando al terreno más técnico y práctico de este artículo hay algunas consideraciones y conceptos para comenzar a entender este tema son las siguientes:
- Un Web Service se puede registrar para poder dejarlo a disposición para otros usuarios y para que los mismos puedan localizarlos. Un mecanismo para registrar estos servicios es por medio de UDDI sigla que obedece a Universal Description, Discovery and Integration, un “repositorio de Web Services” (http://www.uddi.org/). Para registrar un servicio tendrá que tener en cuenta suministrar la información de su empresa, en que categorías ubicaría su servicio y la interfaz a utilizar para consumir dicho servicio.
- El mecanismo utilizado por un Web Service para especificar de qué forma hay que proporcionarle los datos, de forma tal que cualquiera pueda interaccionar con el mismo, es por medio de lenguaje XML. Esta información se almacena en un archivo llamado WSDL (Web Services Description Language).
Este archivo contiene un documento XML junto con la descripción de ciertos mensajes SOAP y como deben intercambiarse, así como también donde esta el recurso del servicio y con que protocolo debe dialogar quien lo consume.
- El protocolo de comunicación utilizado es el SOAP generalmente, el cual es relativamente sencillo de utilizar.
- Los Web Services utilizan protocolos comúnmente conocidos y difundidos como el formato XML, TCP/IP como protocolo de transporte y HTTP como protocolo de transferencia de hipertexto.
¿Qué es el SOAP?
Es un protocolo que define el formato XML para los mensajes de intercambio en el uso de un Web Service. Para aquellos programadores que solían utilizar llamadas del tipo RPC, SOAP también las soporta. Adicionalmente es posible mediante SOAP definir un mensaje HTTP y este punto es de especial interés puesto que el protocolo imprescindible para Internet es HTTP.
Recomendación: Para comenzar a acercarse a entender este tema es recomendable el uso del Microsoft SOAP Toolkit Version 3.0 (pasaje de COM a SOAP).
Un ejemplo práctico
A partir de ahora describiré en unos pocos pasos un ejemplo práctico y sencillo de creación de un Web Service y una muestra de cómo consumirlo desde una aplicación cliente en este caso una simple planilla de Excel.
Paso 1: Lo primero será crear un proyecto Visual Basic del tipo “ASP.NET Web Service” al que llamaremos “DameCotizacion”.
Paso 2: Al archivo Service1.asmx que se crea una vez generado el proyecto lo renombramos a DameCotizacion.asmx y lo establecemos como “Pagina de Inicio del proyecto”.
Paso 3: Ingresando a la ventana de código del archivo DameCotizacion.asmx en la zona del <webMethod()> agregamos el código siguiente:
<WebMethod()> Public Function GetCotizacion(ByVal strmoneda As String) As String 'Objetivo: Devolver cotizacion para una moneda en pesos uruguayos ' Obviamente esto es un ejemplo por lo que esta info que ' se presenta estatica se tomaria de una base de datos 'Acepta: strmoneda - un id para la moneda de dos caracteres. 'Devuelve: cotizacion de dicha moneda en pesos uruguayos Select Case UCase(Trim(strmoneda)) Case "DO" 'dolar Return "30" Case "RE" 'real Return "9.9" Case "EU" 'Euro Return "33" End Select End Function
Para verificar el correcto funcionamiento de esta aplicación, vamos a ejecutarlo. Para ello apretamos F5 y el resultado esperado se verá en el Internet Explorer. Como se puede ver se ofrece el método GetCotizacion() definido en el código anterior.
Si clickeamos sobre dicho método podremos ver la especificación del mismo y la definición del tipo de intercambio de mensajes.
Paso 4: Podemos comprobar el funcionamiento colocando el valor “EU” (código que establecimos para el euro) y clickeando en “Invoke”. El valor esperado por el método es del tipo string y deberá ser uno de los tipo de monedas (“DO”, “RE” o “EU”) definido en nuestro método.
El resultado debería ser un mensaje en XML como se muestra a continuación, mostrando el valor definido para la moneda de código “EU”
Pues bien pongamos a trabajar nuestro Web Service en una aplicación práctica. Supongamos que tenemos una planilla Excel donde tenemos artículos cuyos precios están en su moneda original y queremos que aparezca su valor en pesos uruguayos. Para esto consumiremos el Web Service creado en los pasos anteriores (DameCotizacion) que proporcionando el código de la moneda me devuelve la cotización correspondiente.
Nota: Para este ejemplo debemos tener instalado el paquete Microsoft Web Services Toolkit.
Paso 5: Crearemos una planilla Excel como se muestra en la figura siguiente, donde agregaremos un botón cuyo nombre y Caption será "Cotizar".
Paso 6: En la celda E2 la fórmula para calcular el valor del articulo en pesos uruguayos es =D2*C2. La columna Cotización será alimentada una vez que se oprima el botón Cotizar el cual disparará un evento que consumirá el Web Service DameCotizacion y retornará en cada celda Cotización el valor correspondiente.
Paso 7: Haciendo doble clic sobre el botón Cotizar ingresaremos a la ventana de código Visual Basic posicionados en el evento click de dicho botón.
Previo a esto relacionaremos nuestro Web Service a nuestra planilla mediante el uso de la herramienta Microsoft Web Services Toolkit.
Paso 8: Para ello desde el menú Herramientas de la ventana de código Visual Basic seleccionamos la opción “Web Service References …”
En dicha ventana seleccionamos “Web Service URL” y colocamos http://localhost/DameCotizacion/DameCotizacion.asmx en el cuadro de texto “URL” y apretamos el botón “Search”. Esta acción deberá traer como resultado nuestro Web Service DameCotizacion en la sección “Search Results”, el cual seleccionaremos, donde podrá verse que esta disponible nuestro método GetCotizacion(). Clickearemos “Add”.
Paso 9: El código del evento Cotizar_Click()es el siguiente:
Private Sub Cotizar_Click()
Dim clsCotizacion As clsws_DameCotizacion
Dim monedas As Range
Dim moneda As Range
Dim cotizacion As String
Set clsCotizacion = New clsws_DameCotizacion
Set monedas = Range(Range("b2"), Range("b65536").End(xlUp))
Application.ActiveSheet.Range("b2").Activate
For Each moneda In monedas
cotizacion = clsCotizacion.wsm_GetCotizacion(moneda)
moneda.Offset(0, 1).Value = Val(cotizacion)
Next moneda
End Sub
Ok, si todo sale como es de esperar el resultado de oprimir el botón Cotizar debiera ser el que se muestra a continuación, Eureka!!!!
Como verán este es un simple ejemplo que muestra como consumir un Web Service desde una aplicación cliente en este caso Excel que ilustra dos puntos interesantes: la facilidad de implementación del mismo y la potencia que nos brinda. Basta conocer un proveedor de un servicio de cotizaciones de moneda para mantener nuestra planilla al día con las últimas cotizaciones del mercado bursátil.
Para aquellos desarrolladores que ya hacían uso de incluir referencia a objetos COM en sus herramientas quizás esto no sea muy novedoso pero en el caso de los objetos COM los mismos debían estar físicamente en la computadora cliente. En el caso de los Web Services estamos hablando de compartir recursos que habiten en la Intranet corporativa o mas aún, en Internet y en sitios bien dispersos en el mundo.
Para los que quieran hacer números y le quieran sacar un beneficio económico, ¿qué ocurriría si yo fuera un proveedor de Web Services y solicite la subscripción para el uso de los mismos a mis clientes a lo largo y ancho del planeta? ¿Interesante, no?
Mas aun, no necesariamente el escenario se limita a una aplicación cliente consumiendo un Web Service sino que a su vez un Web Service podría consumir otro Web Service para poder armar la información de respuesta a retornar al cliente. No hace falta Imaginar un escenario de este tipo pues esto ya es posible.
Hacia donde vamos
Si bien se ha avanzado mucho al respecto y hay infinidad de desarrolladores trabajando en este tema hay aspectos a mejorar para catapultar aun más esta funcionalidad. Algunas características a mejorar pasan por temas relacionados a la seguridad (autorización, autenticación y cifrado) en el intercambio de mensajes, manejar el modelo transaccional y poder confirmar la entrega efectiva de los mensajes que se intercambian a través de los Web Services. Adicionalmente se continúa trabajando en la estandarización de los principales actores como ser el WDSL y SOAP. Muchos fabricantes seguirán contribuyendo elaborando herramientas para facilitar el manejo y elaboración de Web Services como en el caso de Microsoft y su Web Services Toolkit para el Office 2003 que actualmente esta en su versión 2.01.
Otros elementos claves que no entran en análisis en este articulo pero igual los menciono por si es de interés del lector ahondar en los mismos, son los relacionados a las especificaciones de WS-Security, WS-Routing y DIME para lo cual pueden encontrar mas información en la herramienta Microsoft WSDK Technology Preview o Internet.
Hola amigo, en este caso me atrevo a preguntar si yo quiero enviar mi contenido de un xml desde una apicacion vb.net windows forms, mediante una funcion o subrutina, que deberia enviar mi variable con el xml(valor) a un webservice (no localhost), tengo que utilizar un webmethod o como seria el code para conectarme y enviar mi xml desde archivo.
ResponderEliminarComo funciona esto?