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.
No hay comentarios.:
Publicar un comentario