Web Services

Descargar como pdf o txt
Descargar como pdf o txt
Está en la página 1de 13

Web Services

Abstract
En los últimos tiempos ha surgido con mucha fuerza el concepto de ‘web services’, incluso
afirmándose que el mismo cambiaría 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 introducción de los estándares en los cuales se basa
este modelo como ser SOAP, WSDL y UDDI.

¿Qué es un web service?


Un web service es una aplicación que puede ser descripta, publicada, localizada e invocada
a través 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 cómo fueron
implementados. A diferencia de la actual tecnología de componentes, no son accedidos por
medio de protocolos específicos 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 términos 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 programación, solo tiene
que poder crear y consumir los mensajes definidos por la interface de los web services.

El modelo de web services.


La arquitectura básica del modelo de web services describe a un consumidor, un proveedor
y ocasionalmente un corredor (broker). Relacionados con estos agentes están las
operaciones de publicar, encontrar y enlazar.

La idea básica consiste en que un proveedor publica su servicios en un corredor, luego un


consumidor se conecta el corredor para encontrar los servicios deseados y una vez que lo
hace se realiza un lazo entre el consumidor y el proveedor.

Cada entidad puede jugar alguno o todos los roles.


Por todo lo anterior hay ciertos requerimientos a la hora de desarrollar o consumir un web
services:

• Una forma estándar de representar los datos.

XML es la opción obvia para este requerimiento.

• Un formato común y extensible de mensajes.

SOAP es el elegido en este caso; SOAP es un protocolo liviano para el intercambio de


información. Más adelante en este documento lo veremos con más detalle.

• Un lenguaje común y extensible para describir los servicios.

La opción en este caso es WSDL. Es un lenguaje basado en XML desarrollado en forma


conjunta por IBM y Microsoft. Lo veremos con más detalle más adelante en este
documento.

• Una forma de descubrir los servicios en Internet.

UDDI se utiliza en este caso; el mismo especifica un mecanismo para publicar y


localizar los servicios por parte de los proveedores y consumidores respectivamente.
Se verá con más detalle más adelante en este documento.

Ventajas y retos.
Los web services apuntan a ser la piedra fundamental de la nueva generación de sistemas
distribuidos. Estos son algunos puntos para fundamentar esta afirmación:

• 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 tecnologías pueden implementar o acceder web
services. Muy pronto estarán presentes en teléfonos, autos e incluso máquinas
expendedoras, las que avisarán a la central cuando el stock sea menor al indicado.

• Encapsular reduce la comlejidad

Todos los componentes en un modelo de web services son web service. Lo importante es la
interface que el servicio provee y no como esta implementado, por lo cual la complejidad se
reduce.

• Fácil de utilizar:

El concepto detrás de los web services es fácil de entender, incluso existen toolkits de
vendedores como IBM o Microsoft que permiten a los desarrolladores crear web services
en forma rápida y fácil.

• Soporte de la Industria:

Todos las empresas de software importantes soportan SOAP, e incluso están 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 podrían ser
consumidos por un web service desarrollado utilizando VisualAge de IBM y viceversa.

A la vez hay ciertos retos técnicos que los web services tienen que sortear para poder tener
éxito. Muchos de estos retos están relacionados con el ambiente abierto en el que tienen
que sobrevivir. Estos son algunos de esos puntos:

• Descubrimiento:

¿Cómo un web service se anuncia para ser descubierto por otro servicio? ¿Qué pasa si el
servicio se cambió o se movió luego de ser anunciado?

WSDL y UDDI son dos nuevos estándares que manejan este punto.

• Confiabilidad:

Algunos web services son más confiables que otros. ¿Cómo puede ser medida esa
confiabilidad y comunicada? ¿Qué pasa cuando un web service esta off-line en forma
temporaria? ¿Localizamos y utilizamos un servicio alternativo brindado por otra empresa o
esperamos a que el servicio este de nuevo on-line?

• Seguridad:

Muchos web services son publicados para ser utilizados sin ninguna restricción, pero
muchos otros van a necesitar autenticación para que los utilicen solo los usuarios
autorizados. ¿Cómo autentifica a los usuarios un web service? ¿Lo hace a nivel del método
que lo implementa o utiliza otro web service para realizar la autenticación?

• Responsabilidad

En caso de que el web service no sea de acceso libre, ¿Cómo puedo definir cuantas veces
un consumidor puede acceder al web service una vez contratado? ¿Cómo se cobra su uso?
¿Cómo se indica que un servicio ya no está más en línea?

Tecnologías asociadas
El modelo de web services está basado en ciertas tecnologías emergentes que es el
resultado del trabajo de varias compañías y organizaciones entre las cuales se destacan IBM
y Microsoft.

Estas tecnologías son SOAP, WSDL y UUDI.

SOAP (Simple Object Access Protocol)

SOAP es un protocolo para el intercambio de información en un ambiente descentralizado


y distribuido. Es el protocolo más utilizado para realizar el intercambio de información en
el modelo de web services.

Está basado en XML y potencialmente puede ser utilizado en combinación con una
variedad de protocolos de comunicación, siendo el más utilizado HTTP. Por lo tanto se
utiliza HTTP para transportar la información, y XML para representar la misma.

El protocolo completo se puede encontrar en http://www.w3.org/TR/soap

EL MODELO DE COMUNICACIÓN DE SOAP

El modelo de comunicación de SOAP es muy similar al de HTTP. Un cliente hace un


requerimiento (request), el servidor que esta escuchando los requerimientos lo atiene y
responde (response) brindando la información solicitada o enviando un mensaje de error en
caso de que el requerimiento no haya sido válido.
El mensaje SOAP consiste en un elemento envelope SOAP obligatorio, un cabezal SOAP
opcional y un cuerpo SOAP obligatorio como un documento XML. El cabezal SOAP es
utilizado para definir información acerca del requerimiento, mientras que el cuerpo SOAP
contiene el método llamado y los parámetros con los que se llama al mismo.

Todo esto es un modelo de mensajes request/response con una forma de describir un


conjunto de métodos y pasarle a los mismos parámetros. Esto parece la base del protocolo
RPC y de hecho es el uso más común de SOAP. El potencial es entregar esto sobre Internet
utilizando HTTP para realizar comunicaciones entre organizaciones permitiendo realizar
comunicaciones entre aplicaciones con diferente plataforma, sistema operativo y lenguaje
de programación.

A continuación se muestra un mensaje SOAP embebido en un request HTTP:

Este ejemplo invoca al servicio StockQuote llamando al método GetLastTradePrice con el


símbolo DIS por parámetro.

Este es la respuesta al requerimiento anterior, el cual retorna el precio de la acción


solicitada:
Si usted quedo asustado por la aparente complejidad del protocolo SOAP pensando lo
engorroso que sería armar los mensajes de requerimiento y parsear los mensajes de
respuesta despreocúpese; la mayoría de los lenguajes de programación proveen o proveerán
soporte para realizar esto. La idea fundamental consiste en utilizar algún objeto al cual se le
brinda un WSDL y se le indica que método se quiere llamar y con que parámetros. Esto
arma en tiempo de ejecución el mensaje SOAP, lo manda y parsea el resultado
adjudicándoselo a alguna variable en forma trasparente para el usuario como si hubiera
hecho un call común.

WSDL: Web Services Description Language

WSDL es un lenguaje basado en XML que se utiliza para describir un Web Services. Ha
sido suministrado por la W3C por estandarización.

Un archivo con formato WSDL provee información de los distintos métodos (operaciones)
que el Web Services brinda, muestra cómo accederlos y que formatos deben de tener los
mensajes que se envían y se reciben. Es como un contrato entre el proveedor del servicio y
el cliente, en el cual el proveedor se compromete a brindar ciertos servicios solo si el
cliente envía un requerimiento con determinado formato. Es el documento principal a lo
hora de documentar un Web Services, pero puede no ser el único. En la mayoría de los
casos es conveniente que este acompañado por un documento escrito en lenguaje natural
que brinde información de que es lo que hace cada uno de los métodos brindados por el
Web Services así como también ejemplos, por ejemplo, de los mensajes SOAP que espera y
responde el servicio.

En forma resumida podríamos decir que un archivo WSDL describe lo siguiente:

• Mensajes que el servicio espera y mensajes que el servicio responde.

• Protocolos que el servicio soporta.

• A donde mandar los mensajes.


FORMATO DE UN ARCHIVO WSDL:

A continuación se muestra como es el formato básico de un archivo WSDL. La


especificación completa de este lenguaje se puede encontrar en
http://www.w3.org/TR/wsdl.html

Un archivo con formato WSDL básicamente contiene los siguientes elementos:

Type: Describe los tipos no estándar usados por los mensajes (Message).

Message: Define los datos que contienen los mensajes pasados de un punto a otro.

PortType: Define una colección de operaciones brindadas por el servicio. Cada operación
tiene un mensaje de entrada y uno de salida que se corresponde con algún Message antes
definido.

Binding: Describe los protocolos que se utilizan para llevar a cabo la comunicación en un
determinado PortType; actualmente los protocolos soportados son SOAP, HTTP GET,
HTTP POST y MIME, siendo SOAP el más utilizado.

Port: Define una dirección (URL) para un determinado Binding

Service: Define una colección de Ports.

El siguiente es un ejemplo de archivo WSDL:

El mismo define dos mensajes (Simple.foo y Simple.fooResponse), luego define un método


llamado “foo” el cual recibe el mensaje Simple.foo y retorna el mensaje
Simple.fooResponse. A continuación se define un binding para el método foo asociándolo
con el protocolo SOAP. Por último se da una URL física que implementa lo antes descrito.
INTERFASE E IMPLEMENTACIÓN

La estructura básica de archivo con formato WSDL podría ser dividido en dos partes
lógicas: la interfase del servicio, y la implementación del mismo.

Esta división lógica divide los elementos de la siguiente forma:

Interface del servicio:


Type, Message, PortType, Binding.

Contiene una definición abstracta y reusable del servicio que puede ser instanciada y
referenciada por distintos proveedores del mismo.

Implementación del servicio:

Port, Service.

Contiene una implementación de una determinada Interface del servicio.

A partir de esta división lógica se puede definir por medio de una Interfase del servicio una
estándar 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.

Si al igual que con SOAP se siente preocupado por la complejidad de los archivos WSDL
de nuevo despreocúpese; la mayoría de los lenguajes de programación proveen o proveerán
herramientas para generar en forma automática el archivo WSDL a partir de un
determinado método o función.

UDDI (Universal Description, Discovery and Integration).

UDDI (www.uddi.org) es un proyecto inicialmente propuesto por Ariba, Microsoft e IBM;


es un estándar para registrar y descubrir web services. La idea es que las distintas empresas
registran su información acerca de los web services que proveen para que puedan ser
descubiertas y utilizadas por potenciales usuarios.

La información es ingresada al registro de empresas UDDI, un servicio lógicamente


centralizado, y físicamente distribuido a través de múltiples nodos los cuales replican su
información en forma regular. Una vez que una empresa se registra en un determinado
nodo del registro de empresas UDDI la información es replicada a los otros nodos y queda
disponible para ser descubierta por otras empresas.

EL ESQUEMA UDDI

El modelo de información base utilizado por los registros UDDI es definido en un esquema
XML. Este esquema define cuatro tipos básicos de información, cada uno de los cuales
proveen la clase de información que un usuario necesita saber para utilizar un web service
de otra empresa.

Los cuatro tipos de información son:

• Información del negocio.

Este tipo de información esta definido en el elemento businessEntity. Contiene información


de la empresa, como ser su nombre, los contactos, el tipo de empresa, etc.
• Información del servicio.

Dentro del elemento businnessEntity se encuentran los elementos businessServices, estos


elementos contienen información sobre web services generalmente agrupados por procesos
de negocio o categorías de servicios.

• Información del enlace (binding).

Dentro de cada elemento businessServices se encuentran los elementos


bindingTemplate. Cada uno de ellos brinda una dirección fisica para hacer
contacto con los servicios descriptos anteriormente.

• Información sobre las especificaciones del servicio.

Cada bindingTemplate tiene asociado un tModel, el cual brinda informacíon sobre las
especificaciones del servicio, por ejemplo, como tienen que ser los mensajes que el servicio
espera y responde, etc.

Un tModel puede ser asociado con elementos bindingTemplate de distintas


empresas que brindan la misma especificaión del servicio. Utilizando entonces los
tModels se pueden encontrar todas las empresas que brindan tal servicio.
Por más información sobre el esquema UDDI:

http://www.uddi.org/pubs/ProgrammersAPI_v2.pdf

API UDDI

El acceso al registro UDDI, ya sea para realizar búsquedas o para ingresar o modificar un
registro, se puede realizar a través de una página web que implemente el acceso o
utilizando ciertas interfaces (web services) que provee la especificación de UDDI. Estas
interfaces están descriptas en una API, que puede ser dividida en dos partes lógicas, la API
de consultas y la API de publicación.

Por más información sobre la API UDDI:


http://www.uddi.org/pubs/ProgrammersAPI_v2.pdf

Un ejemplo
Las formas en que se puede realizar negocios utilizando web services es muy variada. El
consumidor podría pagar por utilizar los servicios brindados por un proveedor, o el
proveedor podría 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
continuación.

El ejemplo es tomado de la vida real y es sobre la compañía aérea Southwest. En su portal


http://www.southwest.com/ , esta compañía aérea permite hacer reservas de boletos, pero
además como valor agregado a los clientes permite hacer reservas de hoteles y reservas de
alquileres de autos. Los datos para poder realizar estas reservas están 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 compañía de aviones le brinda un valor
agregado a sus clientes, y los hoteles y rentadoras de autos están expuestos a ser contratos
por potenciales clientes. Es más, estas empresas no publicaron sus servicios para que fueran
exclusivamente utilizados por la compañía aérea, 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
tendrán las empresas que los sepan utilizar en forma adecuada con respecto a las otras.
Imagínese en este caso si usted fuera a reservar boletos de avión y pudiera elegir por una
compañía que además de reservar los boletos le permitiera hacer la reserva de hotel, y otra
que no; ¿por cuál haría la reserva? Por otro lado imagine que usted es dueño de una
rentadora de autos y sabe que su competencia está brindando sus servicios en un portal de
una compañía aérea y usted no, ¿qué haría?.
Bibliografía

• http://www.gxtechnical.com/gxdlsp/pub/genexus/internet/technicalpapers/web_serv
ices.htm
• Web Services Conceptos,Aruitectura Y Aplicaciones. Gustavo Alonso, Fabio
Casati, Harumi Kuno, Vijay Machiraju. Ed.springer. Año 2004
• Java Web Services Up And Running. Martin Kalin Ed. O'reilly, Año 2009
• Java web Services David A Chapell, Tyller Jewell Ed. O'reilly, Año 2002

Introducción
Una de las tareas más importantes a la hora de crear una SOA es definir su modelo de
servicios: o sea, qué servicios hay y qué tareas en concreto hace cada uno. Esto aclara
mucho las tareas a realizar por el sistema y qué elemento del mismo las llevará a cabo, y
permite validar que esos elementos implementarán las necesidades del usuario, previamente
definidas. Lo cual en cualquier sistema es siempre el grueso del diseño arquitectónico del
mismo. Por ello, de la bondad de este resultado depende en gran parte el éxito de la SOA.

Más tarde o más temprano, en una SOA basada en servicios web este modelo se plasmará
en documentos WSDL que definan en detalle las interfaces de cada servicio: operaciones,
datos recibidos, datos devueltos y errores que pueden ocurrir. Estos WSDLs son casi
imprescindibles a la hora de crear los clientes de un servicio, pues facilitan enormemente la
tarea de invocarlo y gestionarlo.

La mayoría de las herramientas de creación de servicios web, como Apache Axis o Visual
Studio .Net, facilitan que primero se implemente el servicio (o un esqueleto del mismo),
por ejemplo en Java, y a partir de él se genere automáticamente el WSDL. Pero lo cierto es
que esta forma de trabajar que promueven estas herramientas es incorrecta por varias
razones. Para empezar, lo normal es crear la interfaz de algo antes de implementarlo, lo que
permite crear los clientes y los servidores en paralelo. Pero sobre todo es que si creamos el
WSDL a partir del código, tenemos bastantes posibilidades de que los detalles de este
WSDL dependan de la herramienta que hemos usado para generarlo. Por tanto, si luego
queremos que ese servicio sea implementado usando una herramienta diferente, o incluso
por una versión superior de esa misma herramienta, puede que ese WSDL cambie, con lo
cual tendríamos que cambiar los clientes de ese servicio. Por ello, lo apropiado es que la
herramienta se adapte al WSDL, y no al revés.

Estos posibles problemas no son imaginaciones, y ha habido proyectos en Software AG que


han tenido problemas por esto, por ejemplo para llamar a servicios creados con Axis desde
el Sun Java Web Services Developer Pack (JWSDP). Los WSDLs generados por Axis
pueden contener referencias a tipos de Java (que no funcionan en .Net), o a construcciones
propias de Axis (que no funcionan en otros clientes de servicios web Java), o incluso cuya
sintaxis no sigue siquiera el estándar WSDL. Eso sí, un cliente Axis no tiene problemas
para conectarse a un servicio web Axis. Pero para conseguir eso no necesitábamos todas
estas complejidades; el beneficio clave de los servicios web es la interoperabilidad, que se
fundamenta en la independencia de las plataformas.
Por todo eso, lo aconsejable es crear el WSDL antes del código, y no al revés. De esta
forma el modelo de los servicios de nuestra SOA no dependerá de las herramientas con las
que se implemente, sino al revés, y los clientes de los servicios pueden conectarse a ellos
independientemente de si está implementado con Axis, con JWSDP, con .Net o con
cualquier otra herramienta. Y eso es lo que vamos a ver en este tutorial, usando Apache
Axis, claro, que para eso es el más popular. Como todos los entornos de servicios web,
Axis trae una herramienta para crear esqueletos de servicios a partir de WSDL, tanto para
los clientes como para los servicios, llamada WSDL2Java. No es la herramienta definitiva:
el código que genera a veces no compila, y cuando compila puede no cumplir la interfaz
definida por el WSDL. Pero bueno, en muchos casos sí funciona bien, y en cualquier caso
cuando no lo hace nos da una aproximación al resultado que podemos luego completar.

Conclusiones
Los Web Services son uno de los pilares de los proyectos de integración, ya que permiten la
comunicación entre aplicaciones de distinto lenguaje ejecutadas sobre cualquier La
arquitectura SOA favorece en gran medida el mantenimiento y escalabilidad de las
aplicaciones, disminuyendo el acoplamiento de módulos. Java EE presenta dos API’s para
el desarrollo de Web services: JAX-RPC y JAX-WS. La mayoría de las implementaciones
actuales de Web Services utilizan JAX-RPC ya que JAX-WS todavía no estáextendido
entre los desarrolladores. JAX-WS es más novedoso y simplifica en gran medida el
desarrollo de Web Services por el uso de anotaciones.

También podría gustarte