Programación WebUnidad V

“Servicios Web”

Programación Web

5.1 Visión general de servicios Web XML.

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 ServicesLa 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.

Programación Web Que es un Servicio Web

Programación Web El modelo de 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 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 localizar los servicios por parte de los proveedores y consumidores respectivamente. Se verá con más detalle mas adelante en este documento.

Programación Web Ventaja y retos de los Servicios Web

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 complejidad

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.  

Programación Web Ventaja y retos de los Servicios Web

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:¿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 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?

ResponsabilidadEn 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 esta más en línea?  

Programación Web

5.2 Tecnologias Subyacentes

Programación Web

5.2.1 SOAP

Programación Web Prótocolos para Web Service

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 cuales se destacan IBM y Microsoft. Estas tecnologías son SOAP, WSDL y UUDI.

Los dos prótocolos más usados son XML-RPC, y SOAP pero son incompatibles.

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.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. 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 SOAPEl 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.

Programación Web Ventajas de SOAP

El mensaje SOAP consiste en un elemento envelope SOAP obligatorio, un cabezal SOAPopcional y un cuerpo SOAP obligatorio como un documento XML. El cabezal SOAP es utilizadopara definir información acerca del requerimiento, mientras que el cuerpo SOAP contiene elmé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 unconjuntode métodos y pasarle a los mismos parámetros. Esto parece la base del protocoloRPC y de hecho es el uso más común de SOAP. El potencial es entregar esto sobre Internetutilizando HTTP para realizar comunicaciones entre organizaciones permitiendo realizarcomunicaciones entre aplicaciones con diferente plataforma, sistema operativo y lenguaje deprogramación.

Programación Web Ejemplo de mensaje SOAP

Como podemos ver en esta linea SOAP es un documento XML, y como tal, debe comenzar con el tag <?xml….?> y la versión correspondiente.

Aquí se indica que comienza el envelope (sobre) del mensaje

Un mensaje SOAP debe contener siempre un elemento envelope asociado con el namespace (espacio de nombres) http://www.w3.org/2001/12/soap-envelope.

En esta línea lo que se hace es indicar donde se encuentran definidos los tipos de datos utilizados en el documento.

Esta línea indica el comienzo del Header (encabezado). En esta sección se incluye información específica del mensaje, como puede ser la autenticación.

Como todo documento XML los tags que son abiertos deben ser cerrados, esta línea indica la finalización del Header (encabezado).

Aquí comienza el cuerpo del mensaje, en esta sección se incorpora toda la información necesaria para el nodo final. Por ejemplo, los parámetros para la ejecución, o la respuesta a una petición.

Cualquier tipo de fallo que se produzca será notificado en esta sección. La cual esta contenida dentro del cuerpo del mensaje.

Cierre de la sección Fault. Indica el final del cuerpo del mensaje.Fin del mensaje SOAP. •

<?xml version="1.0"?>

<soap:Envelope

xmlns:soap="http://www.w3.org/2001/12/soap-envelope"

Soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">

<soap:Header> ...

</soap:Header>

<soap:Body> ...

<soap:Fault> ...

</soap:Fault> </soap:Body> </soap:Envelope>

Programación Web

5.2.2 WSDL

Programación Web Qué es WSDL

<?xml version="1.0"> Este es otro documento XML, es por esto que debe comenzar con el tag <?xml .. ?> <definitions> Comienzo del documento, este tag agrupa a todos los demás. <types> Se definen los tipos de datos utilizados en el Web Service. …</types> Fin de la definición de tipos. <message> Se definen los métodos y parámetros para realizar la operación. Cada message puede … consistir en una o más partes (parámetros). </message> Fin de la definición de los parámetros. <portType> Esta sección es la más importante, ya que se definen las operaciones que pueden ser … realizadas, y los mensajes que involucran (por ejemplo el mensaje de petición y el de

respuesta). </portType> Fin de la definición de las operaciones y mensajes. <binding> Se definen el formato del mensaje y detalles del protocolo para cada portType. …</binding> Fin de la definición del formato del mensaje y detalles del protocolo para cada PortType. </definitions> Fin del documento WSDL

Web Services Description LanguageEs un protocolo basado en XML que describe los accesos al Web Service. Podriamos decir que es el manual de operación del web service, porque nos indica cuales son las interfaces que provee el Servicio web y los tipos de datos necesarios para la utilización del mismo.

Programación Web

5.2.3 UDDI

Programación Web Qué es UDDI

<?xml version="1.0"> Este es otro documento XML, es por esto que debe comenzar con el tag <?xml .. ?> <definitions> Comienzo del documento, este tag agrupa a todos los demás.

<types> Se definen los tipos de datos utilizados en el Web Service. …</types> Fin de la definición de tipos. <message> Se definen los métodos y parámetros para realizar la operación. Cada message puede …

consistir en una o más partes (parámetros). </message> Fin de la definición de los parámetros. <portType> Esta sección es la más importante, ya que se definen las operaciones que pueden ser …

realizadas, y los mensajes que involucran (por ejemplo el mensaje de petición y el de respuesta).

</portType> Fin de la definición de las operaciones y mensajes. <binding> Se definen el formato del mensaje y detalles del protocolo para cada portType. …</binding> Fin de la definición del formato del mensaje y detalles del protocolo para cada PortType. </definitions> Fin del documento WSDL

Universal Discovery Description and Integration Es un modelo de directorios para Web Services. Es una especificación para mantener directorios estandarizados de información acerca de los Web Services, sus capacidades, ubicación, y requerimientos en un formato reconocido universalmente. UDDI utiliza WSDL para describir las interfaces de los Web Services. Es un lugar en el cual podemos buscar cuales son los Servicios web disponibles, una especie de directorio en el cual podemos encontrar los Web Services publicados y publicar los Web Services que desarrollemos. http://soapclient.com/uddisearch.html http://uddi.org/find.html

Programación Web ¿Que es NuSOAP?

NuSOAP es un kit de herramientas (ToolKit) para desarrollar Web Services bajo el lenguaje PHP. Esta compuesto por una serie de clases que nos harán mucho más fácil el desarrollo de Web Services. Provee soporte para el desarrollo de clientes (aquellos que consumen los Web Services) y de servidores (aquellos que los proveen). NuSOAP esta basado en SOAP 1.1, WSDL 1.1 y HTTP 1.0/1.1

¿NuSOAP es el único soporte para Web Services en PHP?No, no es el único, existen otros, pero es uno de los que están en una fase de desarrollo mucho más avanzada. Sin ir más lejos, PHP a partir de su versión 5 comienza a dar soporte para SOAP, pero aun esta en fase experimental. ¿Por qué NuSOAP y no otro? Esta en una fase madura de desarrollo. No necesita módulos adicionales. Es muy fácil su instalación y uso  ¿Cómo instalo NuSOAP? La instalación es bastante sencilla, solo basta ir a la pagina en sourceforge de NuSOAP http://sourceforge.net/projects/nusoap/ y bajar el archivo comprimido (es un .zip). Lo descomprimimos en un directorio de nuestro servidor web (como puede ser /lib que es el directorio por default), y listo, ya podemos hacer uso de NuSOAP.

Programación Web Como usarlo?

Página de XMethods (http://xmethods.com/) y buscar algún servicio que pueda ser aplicable por personas de todo el mundo, y que no este limitado a los estados unidos. Buscando entre gran cantidad de Web Services de Cotizaciones, o datos específicos de los Estados Unidos, encontré uno que podía ser implementado en cualquier país, y era ni más ni menos que los datos del clima para todo el mundo. Este Web Service tiene 9 métodos que podemos utilizar (todos ellos se encuentran definidos en el archivo WSDL que se encuentra en http://live.capescience.com/wsdl/GlobalWeather.wsdl .

Los métodos son: getStation(), isValidCode(), listCountries(), searchByCode(), searchByCountry(), searchByLocation(), searchByName(), searchByRegion(), getWeatherReport().

Para el ejemplo solo utilizare el método searchByCountry() y getWeatherReport(). En el ejemplo existen dos archivos: seleccionarLocalidad.php: el cual nos permitirá seleccionar una localidad dado un país (el país esta dado por el valor de la variable $sPais). Este archivo PHP utiliza el método del Web Service searchByCountry() mostrarPronostico.php: el cual mostrara el pronóstico para la localidad seleccionada. Este archivo PHP utiliza el método del Web Service getWeatherReport().   Si queremos ver un listado de los servicios publicados podemos ir a esta página: Cape Science

o a este otro linkMindReef Ambos nos permiten probar los métodos de los Web Services en línea, sin necesidad de un cliente SOAP, esto nos es de utilidad principalmente para ver como funciona cada uno de los métodos.

Programación Web

5.3 Publicación de un servicio Web

Programación Web

5.4 Consumo de un servicio Web

WSDL: Web Services Description LanguageWSDL 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.

Programación Web WSDL - Web Services Description Language

INTERFASE E IMPLEMENTACIÓNLa 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.

Programación Web Ventajas y desventajas

EL ESQUEMA UDDIEl 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 UDDIEl 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 ejemploLas 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 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 usted no, ¿qué haría?.    

Programación Web Ventajas y desventajas

EL ESQUEMA UDDIEl 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 UDDIEl 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 ejemploLas 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 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 usted no, ¿qué haría?.    

Programación Web Ventajas y desventajas