INTRODUCCIN A LA TECNOLOGA WEBSERVICES

Un breve paseo, desde un punto de vista informtico.

La Tecnologa WebServices es el referente actual para la integracin de plataformas heterogneas.

Jorge Cerrejn Rubayo Formador en Nuevas Tecnologas y Desarrollo de Aplicaciones

1

1.- Introduccin a los WebServices. La Tecnologa WebServices es el resultado de combinar estndares y protocolos abiertos ampliamente extendidos y aceptados por la comunidad informtica para resolver dos problemas fundamentales: la integracin de las aplicaciones y la integracin de la informacin que manejan. Por un lado, necesitamos que la heterogeneidad de las plataformas informticas no suponga un problema para la reutilizacin, comparticin y colaboracin de servicios entre sistemas. Por ejemplo, el sistema A dispone de un servicio que el sistema B desea consumir, pero el sistema A se construy con tecnologa Java-J2EE y el sistema B lo hizo con Microsoft .Net. Cmo puede B realizar una solicitud en formato A? Y lo que es ms difcil, Cmo puede el sistema A entender una peticin en el formato tecnolgico de B? Por otro lado, sabemos que los datos son el idioma de las mquinas, y que cada tecnologa emplea sus propias estructuras para referirse a lo mismo. Por ejemplo, En el sistema A se recoge el nombre de una persona en un formato String, mientras que el sistema B lo recoge en una estructura VarChar. Ambos sistemas se refieren a lo mismo, pero no se entienden, ya que uno no sabe lo que significa String y el otro no sabe lo que significa VarChar.

1.- Introduccin a los WebServices. El xito de WebService reside en su los estndares y los protocolos empleados: -XML (Extensible Markup Language): lenguaje para estructurar la informacin que intercambiarn los sistemas de forma sencilla y flexible. -SOAP (Simple Object Access Protocol): Protocolo de comunicacin, basado en XML, que permite invocar a los servicios Web a travs de un protocolo de transporte, como HTTP. Consta de tres partes: una descripcin del contenido del mensaje, unas reglas para la codificacin de los tipos de datos en XML y una representacin de las llamadas RPC para la invocacin y respuestas generadas por el Web Service. - WSDL (Web Services Description Language): es una descripcin XML de las operaciones que ofrece un Web Service, la forma correcta de invocarlos, los mensajes que recibe y que devuelve (incluyendo los posibles errores). -UDDI (Universal Description, Discovery and Integration): Directorio donde es posible publicar los Web Services, permitiendo con ello que los posibles usuarios de ese servicio puedan obtener toda la informacin necesaria para la invocacin y ejecucin del Web Service. Un directorio UDDI ofrece una serie de interfaces que posibilitan tanto la publicacin como la obtencin de informacin sobre los Web Services publicados. La informacin registrada se clasifica segn los siguientes criterios: oInformacin de negocio: acerca de quin publica el servicio. oInformacin de servicio: descripcin del tipo de servicio. oInformacin de enlace: direccin (URL, por ejemplo) para acceder al servicio. -WS-*: Conjunto de extensiones sobre la base de WebServices para ampliar la funcionalidad, operatividad o seguridad, como WS-Security.

1.- Introduccin a los WebServices (continuacin). Podemos decir que los Web Services son pequeos mdulos de servicio formados por varios componentes que permiten ser publicados en directorios e invocados para su ejecucin por otros programas, generando una respuesta en XML (bien formado, empleando la estructuracin de SOAP). No olvidemos que un WebServices puede ofrecer varias operaciones e incluso, la misma operacin de forma diferente (securizado o abierto, usando distintos protocolos o con diferente nivel de servicio). Vamos a ver un ejemplo (como en la vida misma): Una persona esta en su casa y recibe una visita inesperada y deciden salir a cenar a un restaurante etiope. Pero el dueo de la casa, no conoce ningn restaurante de este tipo, as que decide buscar por Internet (2) alguno de estos restaurantes. Despus de 5 minutos, localiza un restaurante etiope que permite realizar una reserva de mesa (teniendo en cuenta el escaso tiempo de preparacin que han tenido). Rellenado el formulario de reserva, lo envan al restaurante a travs de la web (3). En el restaurante, se observa la disponibilidad de mesas para dos personas dentro del intervalo de horas y fecha indicados en la peticin. (4) Hallada la mesa, se devuelve (5) un email al solicitante indicando la confirmacin de la reserva.

1.- Introduccin a los WebServices (continuacin). -(Obviamente, el restaurante primero se publicit (1) en Internet y activ su localizacin en los buscadores de restaurantes exticos). -Con este pequeo ejemplo, podemos ver como participan los distintos elementos de nuestro esquema, ejerciendo roles perfectamente claros. Si creamos un escenario de actores, esto es lo que tendramos:

-Con este pequeo ejemplo, podemos ver como participan los distintos elementos de nuestro esquema, ejerciendo roles perfectamente claros. Si creamos un escenario de actores, esto es lo que tendramos:

1.- Introduccin a los WebServices (continuacin). -Si lo trasplantamos a un plano puramente de sistemas, podemos elaborar un pequeo storyboard sobre los elementos, las tecnologas, su inclusin y su alcance: 1.- Tenemos dos sistemas construidos en distinto momento, lugar y empleando tecnologas diferentes. El sistema A, sabe de la existencia de un servicio del sistema B que le es de utilidad.

2.- Ambos sistemas se comunicarn mediante una red (local o Internet) para realizar distintos traspasos de mensajes (peticiones, respuestas, errores). El protocolo ms sencillo que existe para ello es http, por lo que ser nuestra opcin.

1.- Introduccin a los WebServices (continuacin). 3.- El intercambio de mensajes debe realizarse en una tecnologa que no sea especfica de los extremos ni A ni B, ya que esto restara independencia a la solucin. El lenguaje que nos permite estructurar informacin de forma cmoda con total independencia de las tecnologas concretas que lo lean o escriban es XML.

4.- Pero el solo empleo de XML no es suficiente, ya que A y B tenderan a crear sus propias reglas de estructuracin de la informacin, sin poder garantizar que B pueda ofrecer el mismo servicio a otros sistemas. Por ello, es necesario definir un estndar para que, todo aquel que trabaje con mensajes XML dentro de Web Services los use de la misma manera. Este estndar ser SOAP, que define la forma adecuada de componer los mensajes de solicitud, las respuestas y los errores.

1.- Introduccin a los WebServices (continuacin). 5.- Para que A pueda crear los mensajes de peticin de servicio es necesario que A conozca exactamente que servicios puede solicitar a B y como debe solicitarlos, que informacin debe proporcionar y que resultados puede esperar a obtener. Toda esta informacin queda recogida en un fichero que describe al WebService y sus operaciones: el WSDL.

Ya estamos listos para interconectar ambos sistemas y permitir su cooperacin (de un modo sencillo, donde A conoce perfectamente a B, sus diferencias y sus limitaciones. No hemos usado un directorio ni UDDI).

2.- Lenguajes de programacin y WebServices. WebService es una implementacin fsica de los principios de SOA, fundamentalmente cuando hablamos del concepto de integracin e interoperabilidad. Pero por s solo no funciona, es decir, necesitamos una tecnologa que implemente el servicio que es accesible va WebService. Los lenguajes de programacin ms habituales son los de alto nivel como Java o .Net, aunque no son los nicos, ya que todos los lenguajes de programacin modernos, para no perder capacidades respecto a sus alternativas, han realizado grandes esfuerzos por sumarse al uso de la tecnologa WebServices. Centrndonos en los lenguajes CBA (basados en componentes y objetos), podemos definir la tradicional arquitectura de una aplicacin: Arquitectura bsica:

Arquitectura bsica de una aplicacin que expone/publica webservices:

2.- Lenguajes de programacin y WebServices (continuacin). Arquitectura bsica de una aplicacin que consume webservices

Ejemplo de aplicacin que consume los servicios web que otra expone

10

2.- Lenguajes de programacin y WebServices (continuacin). Ahora, vamos a centrarnos en EDA (Arquitecturas dirigidas por eventos). A lo largo de la historia de la informtica, han sido muchas las formas de denominar al proceso mediante el cual una pieza de software realiza una peticin a otra para obtener un resultado que le es de valor. Podemos recordar de forma directa las palabras seal, mensaje, peticin, etc. La irrupcin del usuario en las aplicaciones nos propone un nuevo nombre, la solicitud o peticin de usuario. Seguimos hablando todo el tiempo del mismo concepto: pedir a una pieza de software que realice una actividad. Cuando cambiamos la orientacin al software por la orientacin al usuario aparece la palabra evento, ya que la tecnologa de interaccin con el usuario denomina de esta forma a las interacciones entre humano y mquina. Avanzando a la actual orientacin al servicio, ampliamos el alcance recuperando algo que habamos olvidado por el camino: si, es cierto, el humano se comunica con las mquinas, pero tambin las mquinas lo hacen entre ellas. As, la palabra evento significa: cualquier seal que el humano puede realizar como peticin de un servicio a una aplicacin, lo que esta puede escuchar y a lo que puede responder, as como todas las seales intermedias que los sistemas se transmiten para colaborar entre s, en un flujo de actividad perfectamente coordinado al que llamaremos orquestacin (principio fundamental de SOA). Todos los lenguajes de programacin modernos usan los eventos para comunicarse bidireccionalmente entre sus componentes, acompaando a menudo a estos eventos con un mensaje que transporta la informacin necesaria para ejecutar una tarea o el resultado de la misma. Cuando hablamos de concurrencia, ejecucin remota, etc los lenguajes suelen ampliar los eventos bsicos con utileras especficas como JMS (Java messaging system).

11

2.- Lenguajes de programacin y WebServices (continuacin). Finalmente, debemos hablar de MDA (Arquitecturas dirigidas por modelos), vital para el xito y supervivencia de las aplicaciones. En resumidas cuentas, MDA nos dice: primero piensa y despus haz, en otras palabras, cuando el diseo de un servicio o componente es adecuado, nos importa menos con qu lenguaje de programacin se va a construir. Si realizamos un diseo centrado en una tecnologa, sabemos de antemano el mximo que podremos esperar de la solucin construida, pero ojo, tambin sus carencias y sus lmites. Es aqu donde WebServices juega un papel fundamental ayudndonos a conectar distintas piezas de servicio (CBA) y aportando todo el mecanismo de seales (EDA) necesario para realizar la colaboracin. As que recuerda, una vez definido y diseado lo que quieres, constryelo aplicando la tecnologa que precises, y si lo necesitas, emplea WebServices para conectar las piezas. La apuesta de Microsoft a esta tecnologa ha quedado clara al presentar su nueva plataforma .NET, la cual soporta fuertemente XML y SOAP.

12

2.- Lenguajes de programacin y WebServices (continuacin). El Microsoft SOAP Toolkit se compone de varias APIs COM, divididas en: -Alto nivel: objetos que simplifican el RPC SOAP a travs de proxies y stubs, basados profundamente en el meta data de XML. Utiliza la API de bajo nivel para hacer este trabajo. -Bajo nivel: objetos que acceden directamente al transporte y la estructura del mensaje SOAP, sin basarse en el meta data de XML. -SMO (Simple Messaging Object): objetos que vuelven fcil de usar mensajes SOAP que contienen XML, en lugar de tener el overhead del RPC Adicionalmente a las APIs, hay numerosas herramientas y utilidades que proveen una gran comodidad para el desarrollo, como por ejemplo: -WSDL Generator: un wizard para generar el meta data XML derivado de un objeto COM, el cual es usado frecuentemente junto con la API de alto nivel. -WSDL and WSML API : una API adicional para la lectura y escritura de meta data XML -MSSOAPT: un utilitario para debuggear y tracear el progreso de los request y response del SOAP

13