Tema 3.1: Introducción a Servicios Web

Servicios Web (1)











La Web proporciona un mecanismo de transporte universal, eficiente, robusto, escalable y probado tanto en aplicaciones inter-organización como intraorganización. Buena base para la construcción de aplicaciones distribuidas. Un Servicio Web expone un conjunto de puntos de acceso (endpoints) que pueden ser invocados por procesos externos. Están basados en tecnologías surgidas alrededor de la Web:





Típicamente, los puntos de acceso son accedidos mediante HTTP y sus direcciones se expresan mediante URLs. Las invocaciones y las respuestas de las mismas se codifican típicamente mediante XML.

Servicios Web (2)


Podemos distinguir dos aproximaciones:
REST (Representational Style Transfer)









Es un nuevo estilo arquitectónico, no una tecnología. Veremos sus conceptos arquitectónicos en el apartado 3.6 Se basa fundamentalmente en tecnologías existentes: HTTP 1.1 y XML

Servicios web basados en SOAP


En gran medida utiliza un estilo arquitectónico antiguo (aunque con algunas novedades importantes).





Estilo RPC: Permitir al programador invocar operaciones remotas de forma muy parecida a como si fuesen locales.

Se basa en nuevas tecnologías específicas: SOAP, WSDL, UDDI

SOAP, WSDL y UDDI (1)


WSDL (Web Services Description Language)















Los interfaces ofrecidos por un servicio se expresan en WSDL (Web Service Definition Language) Permiten especificar las operaciones expuestas por el servicio, junto con sus parámetros de entrada y sus valores de respuesta. El compilador de WSDL permite generar






Permite especificar en XML las operaciones y tipos de datos de un servicio web. Independiente del lenguaje de programación. Estandarizado por el W3C

Un “Stub” (Proxy) del objeto remoto (cliente) Un Skeleton (Adapter) para implementar el interfaz remoto (servidor)

Esto permite al programador invocar transparentemente las operaciones expuestas por el servicio (estilo arquitectónico “RPC”).

SOAP, WSDL y UDDI (2)


SOAP (originalmente “Simple Object Access Protocol”)


Protocolo basado en XML para envío de mensajes estructurados.








Transmitir las invocaciones junto con sus parámetros y las respuestas de las mismas

Normalmente SOAP funciona sobre HTTP (la alternativa más frecuente), pero admite otros métodos de transporte (SMTP, JMS,…) Estandarizado por el W3C

SOAP, WSDL y UDDI (y 3)


UDDI (Universal Description, Discovery and Integration of Web Services)








Protocolo para interaccionar con un servidor (registro UDDI) que proporciona operaciones (vía SOAP) para registrar y buscar servicios web Cada servicio web se registra dando, su nombre, una descripción del servicio (ej.: la URL de su WSDL, una descripción textual, etc.), etc. Especificación: http://www.uddi.org

APIs para Servicios web SOAP





Existen APIs (comerciales y gratuitas) para los lenguajes más usuales En el caso de Java







Las APIs son estándares Forman parte de JEE Al igual que en CORBA, podemos cambiar de fabricante sin que afecte al código fuente

En el caso de los lenguajes de Microsoft


Las APIs forman parte de .NET

APIs Java


Entre otras


JAXM (Java API for XML Messaging)





JAX-RPC (Java API for XML-based RPC)





Ahora ya obsoleta, pero aún muy utilizada.

JAXR (Java API for XML Registries)





Servicios Web asíncronos.

UDDI

JAX-WS (Java API for XML Web Services)


La nueva API que se reemplaza a JAX-RPC. Es la que estudiaremos.

REST









REpresentational State Transfer. Estilo arquitectónico propuesto por Roy Fielding en 2000. El enfoque REST “puro” no utiliza la idea “RPC”. Sin embargo, el REST “real” mezcla ideas arquitectónicas del estilo REST “puro” y del estilo RPC. En el enfoque REST el protocolo de transporte es siempre HTTP





SOAP puede utilizar diferentes mecanismos de transporte: HTTP, SMTP, JMS … pero casi siempre se usa HTTP.

REST nos obliga a “parsear” el mensaje XML devuelto.


En el enfoque SOAP, manejamos directamente los objetos de nuestro lenguaje de programación (Java, C++).

Ámbito de aplicación de servicios web


Integración de aplicaciones en intranets



Cuando se utilizan, se suele seguir el enfoque SOAP. No son una alternativa tan eficiente y madura como CORBA





Sin embargo






CORBA dispone de numerosos servicios (seguridad, transacciones, etc.) Gozan de “industry momentum” Es una tecnología soportada por todos los fabricantes.

Integración de aplicaciones en Internet (B2B y Mashups)


A pesar de sus inconvenientes frente a CORBA, el enfoque de Servicios Web SOAP es ya el más utilizado en integraciones B2B.





CORBA, RMI y DCOM tienen aún su espacio.

Sobre todo fuera del mundo corporativo (Mashups), REST es muy utilizado, aunque SOAP tiene su espacio:


Pocas veces se utiliza el estilo REST “puro”, aunque está ganando fuerza.