Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Alcance
Lenguajes: Java, .NET, Visual Basic
Interfaces: Win, Web
Introduccin
El WSDL Inspector permite a partir del WSDL de un web service definir los tipos de
datos necesarios en GeneXus para poder consumir el web service en forma
transparente sin tener que preocuparse de los protocolos involucrados en el proceso y
la definicin del mismo.
Descripcin
El WSDL de un web service es un archivo que describe al mismo; brinda toda la
informacin necesaria para poder consumirlo.
GeneXus brinda una herramienta llamada WSDL Inspector que permite a partir del
WSDL de un web service definir en la base de conocimientos todo lo necesario para
poder consumir los mtodos del web service en forma transparente.
Para acceder al WSDL Inspector hay que ejecutar la opcin Tools/WSDL Inspector. La
misma esta solo accesible desde Design.
En Web Service URL se debe ingresar el camino hacia el WSDL. Puede ser
referenciado por medio del protocolo http (por ej.
http://api.google.com/GoogleSearch.wsdl ) o file (por ej.
file:C:\Servicios\AmazonWebServices.wsdl).
Una vez ingresado el camino del WSDL se debe presionar el botn Inspect, con lo
cual en caso de no existir ningn error se mostrar la informacin de los distintos
mtodos que brinda el web service, junto con los tipos de datos necesarios para
poder consumirlos.
Para poder importar la informacin necesaria dentro de la base de conocimientos
que permita consumir el web service se debe presionar el botn Add Reference.
En la imagen anterior se muestra la informacin de un web service simple, el cual
cuenta con un solo mtodo llamado BabelFish que recibe dos parmetros de entrada
de tipo Carcter y retorna otro parmetro de tipo Carcter.
El siguiente ejemplo muestra otro caso en el cual el web service cuenta con mas de
un mtodo y se necesita definir nuevos tipos de datos(ArrayOfNewsCategoty,
NewsCategoty, ArrayOfBusnessShortNews, BusnessShortNews):
Add Reference
Como se mencion anteriormente al presionar el botn Add Reference se genera
dentro de la base de conocimientos los tipos de datos necesarios para poder consumir
el web service en forma trasparente. O sea, se genera un tipo de datos que identifica
el web service y en caso de que el mismo necesite nuevos tipos de datos se genera
un tipo de datos estructurado para cada uno de ellos.
De esta forma se puede definir una variable a la cual asignarle el tipo de datos
definido para el web service y utilizando los mtodos de la misma poder invocar a los
distintos mtodos que el web service provee. Si para consumir el mtodo se
necesitan tipos de datos estructurados hay que crear variables con los tipos de datos
estructurados creados por el Inspector.
(Notar que en el nombre asignado al tipo de datos esta precedido por el namespace
que identifica al web service, de esta forma GeneXus asegura que no van a existir
dos tipos de datos con el mismo nombre para distintos web services).
De esa forma se puede definir una variable a la cual asignarle ese tipo de datos;
llamaremos a la misma ws.
Luego podremos invocar utilizando la variable ws a cualquiera de los mtodos que
el web service provee (en este caso solo uno) de la siguiente forma:
&result = &ws.BabelFish(&traslationmode, &source)
Donde &result, &traslationmode y &source son variables de tipo character.
Eso es todo!, de esta forma se puede invocar a un web service en forma sencilla sin
tener que preocuparse de los protocolos involucrados en el proceso y la definicin del
mismo; solamente se tuvo que dar la ubicacin de su WSDL y GeneXus se encarg de
esconder la complejidad y definir un tipo de datos que represente al web service.
Mtodo con tipo de datos estructurado
Ahora vamos a consumir un webservice que utiliza dos tipos de datos estructurados.
Al importar el webservice en GeneXus se crea la siguiente:
ZodiacSign
Character(9999)
DailyForecast Character(9999)
Un tipo de dato estructurado llamado ArrayOfZodiacSigns con la
siguiente definicin:
<GXLocations>
<GXLocation name="com_swanandmokashi_Horoscope">
<Common>
<Host>localhost</Host>
<Port>88</Port>
</Common>
<HTTP>
<BaseURL>/HomePage/WebServices/</BaseURL>
</HTTP>
</GXLocation>
</GXLocations>
Ejemplo
En el GXOpen se encuentra una KB de ejemplo en la cual se consumen tres web
services; GXChart (servidor de grficas), Babelfish (traductor de textos) y GetJoke
(provee chistes agrupados por categoras).
El mismo puede ser obtenido en http://www.gxopen.com/main/hproject.aspx?176
Consideraciones
Para consolidar objetos que tengan variables de tipos de datos asociados a web
services, es necesario previamente agregar la referencia con el WSDL Inspector
en la KB destino. Otra opcin es copiar los archivos asociados al web service
desde el directorio <dir.KB>\kbdata\usrtypes de la KB origen a la destino (se
generan dos archivos con extensiones .ari y .xml por cada web service agregado,
que contienen las definiciones del mismo). Adems, luego de consolidarlo, es
necesario en el objeto borrar y volver a definir la/s variable/s de ese tipo, de lo
contrario se producir un error de especificacin:
spc0056, Internal error. Variable <variable> definition is incorrect or
not available. Data:<tipo>.
No se puede utilizar el WSDL Inspector para consumir web services con los
generadores VFP y C/SQL
WEB SERVICES
Abstract
En los ltimos tiempos ha surgido con mucha fuerza el concepto de web
services, incluso afirmndose que el mismo cambiara la forma de programar
las aplicaciones orientadas a Internet hacia una arquitectura orientada a
servicios. Todo esto se ha visto potenciado luego del anuncio de Microsoft de su
nueva estrategia .NET que est basada en el modelo de web services.
Este documento describe que son los web services y como es la arquitectura
general del modelo, adicionalmente se provee una introduccin de los
estndares en los cuales se basa este modelo como ser SOAP, WSDL y UDDI.
Qu es un web service?
Un web service es una aplicacin que puede ser descripta, publicada,
localizada e invocada a travs de una red, generalmente Internet. Combinan
los mejores aspectos del desarrollo basado en componentes y la Web.
Al igual que los componentes, los web services son funcionalidades que se
encuentran dentro de una caja negra, que pueden ser reutilizados sin
preocuparse de cmo fueron implementados. A diferencia de la actual
tecnologa de componentes, no son accedidos por medio de protocolos
especficos del modelo de objetos como ser RMI, DCOM o IIOP; sino que son
accedidos utilizando protocolos web como ser HTTP y XML.
La interface de los web services esta definida en trminos de los mensajes que
el mismo acepta y retorna, por lo cual los consumidores de los web services
pueden ser implementados en cualquier plataforma y en cualquier lenguaje de
programacin, solo tiene que poder crear y consumir los mensajes definidos
por la interface de los web services.
Ventajas y retos.
Los web services apuntan a ser la piedra fundamental de la nueva generacin
de sistemas distribuidos. Estos son algunos puntos para fundamentar esta
afirmacin:
Interoperabilidad:
Cualquier web service puede interactuar con otro web service. Como los web
services pueden ser implementados en cualquier lenguaje, los desarrolladores
no necesitan cambiar sus ambientes de desarrollo para producir o consumir
web services.
Ubicuidad:
Los web services se comunican utilizando HTTP y XML. Por lo tanto
cualquier dispositivo que soporte estas tecnologas pueden implementar
o acceder web services. Muy pronto estarn presentes en telfonos,
autos e incluso mquinas expendedoras, las que avisarn a la central
cuando el stock sea menor al indicado.
Fcil de utilizar:
El concepto detrs de los web services es fcil de entender, incluso existen
toolkits de vendedores como IBM o Microsoft que permiten a los
desarrolladores crear web services en forma rpida y fcil.
Soporte de la Industria:
Todos las empresas de software importantes soportan SOAP, e incluso estn
impulsando el desarrollo de web services. Por ejemplo la nueva plataforma de
Microsoft .NET esta basada en web services, haciendo muy simple el
desarrollo de los mismos que luego podran ser consumidos por un web
service desarrollado utilizando VisualAge de IBM y viceversa.
A la vez hay ciertos retos tcnicos que los web services tienen que sortear para poder
tener xito. Muchos de estos retos estn relacionados con el ambiente abierto en el
que tienen que sobrevivir. Estos son algunos de esos puntos:
Descubrimiento:
Como un web service se anuncia para ser descubierto por otro servicio? Qu
pasa si el servicio se cambio o se movi luego de ser anunciado?
WSDL y UDDI son dos nuevos estndares que manejan este punto.
Confiabilidad:
Algunos web services son ms confiables que otros. Cmo puede ser medida
esa confiabilidad y comunicada? Qu pasa cuando un web service esta offline en forma temporaria? Localizamos y utilizamos un servicio alternativo
brindado por otra empresa o esperamos a que el servicio este de nuevo online?
Seguridad:
Muchos web services son publicados para ser utilizados sin ninguna
restriccin, pero muchos otros van a necesitar autenticacin para que los
utilicen solo los usuarios autorizados. Cmo autentifica a los usuarios un web
service? Lo hace a nivel del mtodo que lo implementa o utiliza otro web
service para realizar la autenticacin?
Responsabilidad
En caso de que el web service no sea de acceso libre, Cmo puedo definir
cuantas veces un consumidor puede acceder al web service una vez
Tecnologas asociadas
El modelo de web services est basado en ciertas tecnologas emergente que
es el resultado del trabajo de varias compaas y organizaciones entre las
cuales se destacan IBM y Microsoft.
Estas tecnologas son SOAP, WSDL y UUDI.
Type: Describe los tipos no estndar usados por los mensajes (Message).
Message: Define los datos que contienen los mensajes pasados de un punto a
otro.
INTERFASE E IMPLEMENTACIN
La estructura bsica de archivo con formato WSDL podra ser dividido en dos
partes lgicas: la interfase del servicio, y la implementacin del mismo.
A partir de esta divisin lgica se puede definir por medio de una Interfase del
servicio una estndar para realizar, por ejemplo, ordenes de compras que
puede ser reutilizada e implementada por todas las empresas, sin tener que
redefinir cada una de ellas la interfase.
EL ESQUEMA UDDI
El modelo de informacin base utilizado por los registros UDDI es definido en
un esquema XML. Este esquema define cuatro tipos bsicos de informacin,
cada uno de los cuales proveen la clase de informacin que un usuario necesita
saber para utilizar un web service de otra empresa.
Los cuatro tipos de informacin son:
API UDDI
El acceso al registro UDDI, ya sea para realizar bsquedas o para ingresar o modificar
un registro, se puede realizar a travs de una pgina web que implemente el acceso o
utilizando ciertas interfaces (web services) que provee la especificacin de UDDI.
Estas interfaces estn descriptas en una API, que puede ser dividida en dos partes
lgicas, la API de consultas y la API de publicacin.
Un ejemplo
Las formas en que se puede realizar negocios utilizando web services es muy
variada. El consumidor podra pagar por utilizar los servicios brindados por un
proveedor, o el proveedor podra pagar para que aparezcan los servicios que l
ofrece en un determinado consumidor, o incluso existen casos en los cuales ni
el consumidor ni el proveedor pagan por consumir o proveer los servicios en
forma respectiva. Este es el caso que se presenta a continuacin.
El ejemplo es tomado de la vida real y es sobre la compaa area Southwest.
En su portal http://www.southwest.com/ , esta compaa area permite hacer
reservas de boletos, pero adems como valor agregado a los clientes permite
hacer reservas de hoteles y reservas de alquileres de autos. Los datos para
poder realizar estas reservas estn tomados de web services que brindan los
distintos hoteles y rentadoras de autos.
Este es un ejemplo de uso de web services en el cual ni el consumidor ni los
proveedores pagan; a ambos le sirve este intercambio ya que la compaa de
aviones le brinda un valor agregado a sus clientes, y los hoteles y rentadoras
de autos estn expuestos a ser contratos por potenciales clientes. Es ms,
estas empresas no publicaron sus servicios para que fueran exclusivamente
utilizados por la compaa area, sino que los mismos pueden ser descubiertos
y utilizados por cualquier empresa que los necesite.
Claramente se muestra en este ejemplo el gran poder de los web services, y la
ventaja que tendrn las empresas que los sepan utilizar en forma adecuada
con respecto a las otras. Imagnese en este caso si usted fuera a reservar
boletos de avin y pudiera elegir por una compaa que adems de reservar los
boletos le permitiera hacer la reserva de hotel, y otra que no; por cual hara la
reserva? Por otro lado imagine que usted es dueo de una rentadora de autos y
sabe que su competencia esta brindando sus servicios en un portal de una
compaa area y usted no, qu hara?.