Back to top
1) Abstract
En los últimos tiempos ha surgido con mucha fuerza el término de ‘web services’, aun afirmándose que el mismo cambiaría la forma de programar las aplicaciones orientadas a Internet cara 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, de forma adicional se provee una introducción de los estándares en los cuales se fundamenta este modelo como ser SOAP, WSDL y UDDI.
Back to top
2) ¿Qué es un web service?
Un web service es una aplicación que puede ser descrita, publicada, localizada y también invocada a través de una red, por norma general 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 vueltos a utilizar sin preocuparse de cómo fueron incorporados. En contraste a la presente tecnología de componentes, no son accedidos a través 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 regresa, por lo cual los consumidores de los web services pueden ser incorporados en cualquier plataforma y en cualquier lenguaje de programación, solo tiene que poder crear y consumir los mensajes definidos por la interfaz de los web services.
Back to top
3) El modelo de web services.
La arquitectura básica del modelo de web services describe a un consumidor, un distribuidor 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 hallar los servicios deseados y una vez que lo hace se efectúa un nudo entre el consumidor y el distribuidor.
Cada entidad puede jugar alguno o bien todos y cada uno de los papeles.
Por todo lo precedente 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 vamos a ver con más detalle.
- Un lenguaje común y extensible para describir los servicios.
La opción en un caso así es WSDL. Es un lenguaje basado en XML desarrollado en forma conjunta por IBM y Microsoft. Lo veremos con más detalle mas 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 encontrar los servicios por la parte de los proveedores y usuarios respectivamente. Se verá con más detalle pero adelante en este documento.
Back to top
4) Ventajas y desafíos.
Los web services apuntan a ser la piedra esencial de la nueva generación de sistemas distribuidos. Estos son ciertos puntos para fundamentar esta afirmación:
Cualquier web service puede interaccionar con otro web service. Como los web services pueden ser incorporados en cualquier lenguaje, los desarrolladores no necesitan mudar sus ambientes de desarrollo para producir o consumir web services.
Los web services se comunican utilizando HTTP y XML. En consecuencia cualquier dispositivo que soporte estas tecnologías pueden implementar o bien acceder web services. Muy pronto estarán presentes en teléfonos, autos e inclusive 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 esencial es la interface que el servicio provee y no como esta implementado, por lo cual la dificultad se reduce.
El concepto detrás de los web services es fácil de comprender, aun existen toolkits de vendedores como IBM o bien Microsoft que permiten a los desarrolladores crear web services en forma rápida y fácil.
- Soporte de la Industria:
Todos las compañías de software esenciales aguantan 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 entonces podrían ser consumidos por un web service desarrollado utilizando VisualAge de IBM y viceversa.
A la vez hay determinados 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:
¿Como un web service se anuncia para ser descubierto por otro servicio? ¿Qué pasa si el servicio se cambio o bien se movió después de ser anunciado?
WSDL y UDDI son 2 nuevos estándares que manejan este punto.
· Confiabilidad:
Algunos web services son más fiables que otros. ¿Cómo puede ser medida esa confiabilidad y comunicada? ¿Qué pasa en el momento en que un web service esta off-line en forma temporaria? ¿Localizamos y empleamos un servicio alternativo brindado por otra empresa o bien esperamos a que el servicio este nuevamente en línea?
· Seguridad:
Muchos web services son publicados para ser utilizados sin restricción, mas muchos otros van a precisar 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 incorpora o emplea 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 empleo? ¿Cómo se indica que un servicio ya no esta más en línea?
Back to top
5) Tecnologías asociadas
El modelo de web services está basado en ciertas tecnologías emergente que es el resultado del trabajo de varias compañías y organizaciones entre las que se destacan IBM y Microsoft.
Estas tecnologías son SOAP, WSDL y UUDI.
5.1) 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 efectuar el intercambio de información en el modelo de web services.
Esta 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. En consecuencia se utiliza HTTP para transportar la información, y XML para representar la misma.
El protocolo completo se puede encontrar en
5.1.1) El modelo de comunicación de SOAP
El modelo de comunicación de SOAP es muy similar al de HTTP. Un cliente del servicio hace un requerimiento (request), el servidor que esta escuchando los requerimientos lo ajusta y responde (response) brindando la información solicitada o bien mandando un mensaje de fallo en caso de que el requerimiento no haya sido válido.
El mensaje SOAP consiste en un factor envelope SOAP obligatorio, un cabezal SOAP opcional y un cuerpo SOAP obligatorio como un documento XML. El cabezal SOAP es empleado para acotar información acerca del requerimiento, al tiempo 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 semeja la base del protocolo RPC y de hecho es el empleo más común de SOAP. El potencial es dar esto sobre Internet usando HTTP para efectuar comunicaciones entre organizaciones dejando 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 precedente, el cual retorna el costo de la acción solicitada:
Si 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 bien proveerán soporte para realizar esto. La idea fundamental consiste en emplear algún objeto al que se le ofrece un WSDL y se le señala 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.
5.2) 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 usuario, en el cual el distribuidor se compromete a brindar determinados 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 servirnos de un 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 aguanta.
· A donde enviar los mensajes.
5.2.1) 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 localizar en
Un archivo con formato WSDL básicamente contiene los siguientes elementos:
Type:Describe los tipos no estándar utilizados por los mensajes ( Message).
Message:Define los datos que poseen 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 Messageantes definido.
Binding:Describe los protocolos que se utilizan para realizar la comunicación en un determinado PortType; en nuestros días 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 caso del archivo WSDL:
El mismo define dos mensajes (Simple.foo y Simple.fooResponse), entonces define un método llamado “foo” el que 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 incorpora lo ya antes descrito.
5.2.2) Interfase e implementación
La estructura básica de archivo con formato WSDL podría ser dividido en 2 partes lógicas: la interfase del servicio, y la implementación del mismo.
Esta división lógica divide los elementos de la próxima forma:
Interface del servicio:
Type, Message, PortType, Binding.
Contiene una definición abstracta y reusable del servicio que puede ser instanciada y referenciada por diferentes distribuidores 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 serviciouna estándar para efectuar, por servirnos de un 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 de la misma manera que con SOAP se siente preocupado por la complejidad de los ficheros 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 fichero WSDL desde un determinado método o bien función.
5.3) UDDI (Universal Description, Discovery and Integration).
UDDI () es un proyecto en un inicio propuesto por Ariba, Microsoft y también IBM; es un estándar para registrar y descubrir web services. La idea es que las diferentes empresas registran su información sobre los web services que proveen para poder ser descubiertas y empleadas 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 contestan su información en forma regular. Una vez que una compañía se registra en un determinado nodo del registro de empresas UDDI la información es replicada a los otros nodos y queda libre para ser descubierta por otras empresas.
5.3.1) El esquema UDDI
El modelo de información base empleado por los registros UDDI es definido en un esquema XML. Este esquema define 4 tipos básicos de información, cada uno de ellos de los cuales proveen la clase de información que un usuario necesita saber para emplear un web service de otra empresa.
Los 4 tipos de información son:
· Información del negocio.
Este tipo de información esta definido en el factor businessEntity. Contiene información de la empresa, como ser su nombre, los contactos, el género de empresa, etc.
· Información del servicio.
Dentro del elemento businnessEntity se encuentran los elementos businessServices, estos elementos poseen información sobre web services generalmente agrupados por procesos de negocio o bien categorías de servicios.
· Información del link (binding).
Dentro de cada elemento businessServices se hallan los elementos bindingTemplate. Cada uno de ellos brinda una dirección física para hacer contacto con los servicios descritos anteriormente.
· Información sobre las especificaciones del servicio.
Cada bindingTemplate tiene asociado un tModel, el que 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 diferentes empresas que brindan la misma especificaión del servicio. Utilizando entonces los tModels se pueden encontrar todas las compañías que brindan tal servicio.
Por más información sobre el esquema UDDI:
5.3.2) API UDDI
El acceso al registro UDDI, así sea para realizar búsquedas o bien para ingresar o bien modificar un registro, se puede efectuar a través de una página web que implemente el acceso o usando 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:
Back to top
6) Un ejemplo
Las formas en que se puede efectuar negocios utilizando web services es muy variada. El consumidor podría pagar por emplear los servicios brindados por un proveedor, o bien el distribuidor podría pagar para que aparezcan los servicios que él ofrece en un determinado consumidor, o bien aun existen casos en los cuales ni el consumidor ni el distribuidor 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, esta compañía aérea permite hacer reservas de billetes, mas además como valor agregado a los clientes deja 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 empleo de web services en el que ni el consumidor ni los proveedores pagan; a ambos le sirve este intercambio puesto que la compañía de aviones le ofrece un valor agregado a sus clientes del servicio, 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 únicamente usados 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 caso de ejemplo el gran poder de los web services, y la ventaja que tendrán las compañías que los sepan utilizar en forma adecuada respecto a las otras. Imagínese en un caso así si usted fuera a reservar boletos de avión y pudiera elegir por una compañía que además de reservar los billetes le permitiera hacer la reserva de hotel, y otra que no; ¿por cual haría la reserva? Por otro lado imagine que usted es dueño de una rentadora de autos y sabe que su competencia esta brindando sus servicios en un portal de una compañía aérea y no, ¿qué haría?.
Back to top
