UNIVERSIDAD PONTIFICA DE SALAMANCA CAMPUS DE MADRID
Estado del Arte de los Servicios Web PRIMER AVANCE DEL TRABAJO DE INVESTIGACION DEA
Edwin Alberto Valencia Castillo 11/04/2008
Estado del Arte de los Servicios Web 2008 INDICE INDICE _________________ INDICE _____________________________________ ________________________________________ ________________________________________ ________________________ ____ 2 INTRODUCCION ___________________ _______________________________________ ________________________________________ __________________________________ ______________ 3 I.
SERVICIOS WEB ___________________ WEB _______________________________________ ________________________________________ ______________________________ __________ 4
1.1. 1.2. 1.3. 1.4. II.
DEFINICION __________________ DEFINICION ______________________________________ _______________________________________ ______________________________ ___________ 4 CARACTERISTICAS ___________________ CARACTERISTICAS _______________________________________ ________________________________________ ________________________ ____ 5 BENEFICIOS _________________ BENEFICIOS _____________________________________ ________________________________________ _______________________________ ___________ 6 ELEMENTOS ______________________________________ _________________________________________________________ ______________________________ ___________ 7
ARQUITECTURA DE SERVICIOS WEB ____________________ _______________________________________ ________________________________ _____________ 10
2.1.
COMPONENTES DE LA ARQUITECTURA _______________________________________ _____________________________________________ ______ 11
2.1.1. 2.1.2. 2.1.3. 2.1.4.
2.2.
OPERACIONES DE LA ARQUITECTURA _____________________________________ _______________________________________________ __________ 12
2.2.1. 2.2.2. 2.2.3.
2.3.
Publicar/Cancelar __________________ ______________________________________ ________________________________________ ____________________12 12 Buscar __________________ ______________________________________ ________________________________________ _____________________________ _________ 12 Enlazar (Bind) Enlazar (Bind) __________________ ______________________________________ ________________________________________ _______________________ ___ 12
MODELOS ARQUITECTONICOS _______________________________________ ____________________________________________________ _____________ 13
2.3.1. 2.3.2. 2.3.3. 2.3.4. III.
Servicio ____________________ Servicio ________________________________________ ________________________________________ __________________________ ______ 11 Proveedor de Proveedor de Servicio ___________________ Servicio _______________________________________ ____________________________________ ________________ 11 Registro de Servicios ____________________ ________________________________________ ____________________________________ ________________ 11 Solicitante de Servicios __________________ Servicios ______________________________________ ____________________________________ ________________ 11
El Modelo El Modelo orientado a mensajes _________________ mensajes _____________________________________ _____________________________ _________ 13 El Modelo El Modelo orientado a servicios __________________ servicios ______________________________________ _____________________________ _________ 14 Modelo orientado a recursos ____________________ recursos ________________________________________ _____________________________ _________ 14 Modelo de Políticas ____________________ ________________________________________ ____________________________________ ________________ 15
ESTANDARES Y ESPECIFICACIONES RELACIONADOS CON LOS SERVICIOS WEB__________________ 16
3.1. 3.2. 3.3. 3.4. 3.5. 3.6. 3.7. IV.
SOAP (SIMPLE OBJECT ACCESS PROTOCOL) _____________________________________ _______________________________________________ __________ 21 WSDL (WEB SERVICE DESCRIPTION LANGUAGE) ______________________________________ ____________________________________________ ______ 23 UDDI (UNIVERSAL DESCRIPTION DISCOVERY AND INTEGRATION) ____________________ _________________________________ _____________ 25 WS‐SECURITY _______________________________________ ___________________________________________________________ __________________________ ______ 26 WS‐POLICY_________________________ POLICY_____________________________________________ ________________________________________ _______________________ ___ 28 WS‐I ____________________ ________________________________________ ________________________________________ _________________________________ _____________ 29 WS‐BPEL _______________________________________ ___________________________________________________________ ______________________________ __________ 29 REST UNA PROPUESTA ALTERNATIVA A SOAP ___________________ _______________________________________ ______________________ __ 31
4.1. 4.2.
DEFINICION __________________ DEFINICION ______________________________________ _______________________________________ _____________________________ __________ 31 PRINCIPIOS ______________________________________ _________________________________________________________ _____________________________ __________ 32
REFERENCIAS BIBLIOGRAFICAS _________________ BIBLIOGRAFICAS _____________________________________ ________________________________________ _______________________ ___ 33
2
Edwin Valencia Castillo
Estado del Arte de los Servicios Web 2008 INTRODUCCION En la actualidad, la web, es la puerta de entrada a todo un conjunto de servicios ofrecidos por empresas o personas independientes, generando gran cantidad de interacciones persona – servicio en la internet, sin embargo, un gran número de interacciones que se genera en la web, se da entre aplicaciones, es decir las empresas tienen que comunicarse con otras empresas para realizar transacciones más complejas. Para establecer dichas comunicaciones, se han creado estándares que se han agrupado bajo la denominación de servicios web. Estos estándares permiten que las empresas categoricen los tipos de servicios que ofrecen, describir cómo debe interactuar con otras aplicaciones y definir como será codificada la información intercambiada entre un cliente y un proveedor de un servicio determinado. En la actualidad, las empresas están usando los servicios web como construcciones básicas para el desarrollo de aplicaciones, creando nuevas arquitecturas de software orientadas a servicios (Service‐ (Service‐Oriented Architecture, SOA), donde las funcionalidades se definen como servicios independientes, con interfaces invocables bien definidas, que pueden ser llamadas en secuencias especificas formando procesos de negocios. El objetivo es ser más flexible, donde las empresas compartan información, procesos y sus mejores prácticas a través de toda la empresa, con capacidades modulares que puedan ser rápidamente configuradas para crear oportunidades y resolver problemas. El presente trabajo busca detallar el estado del arte de los servicios web y sus arquitecturas, tratando de describir sus estándares y nuevas tendencias.
3
Edwin Valencia Castillo
Estado del Arte de los Servicios Web 2008 I.
SERVICIOS WEB
1.1.
DEFINICION
El W3C 1 Web Services Architecture Working Group, define un servicio web como un
sistema software diseñado para soportar la interacción interoperable de maquina a máquina sobre una red. Tiene una interfaz descrita en un formato procesable por un computador (específicamente WSDL). Otros sistemas interactúan con los servicios web en una manera preestablecida por su descripción usando mensajes SOAP, típicamente usando el protocolo HTTP con una serialización XML en conjunto con otros estándares web relacionados.[1] Además, especifica que un servicio web proporciona un medio estándar para inter‐operar entre diferentes aplicaciones software, ejecutándose en una variedad de plataformas y/o frameworks[1] El W3C también define a un servicio web como: Una aplicación software identificada por un URI, cuyas interfaces se pueden definir, describir y descubrir mediante documentos XML. Un servicio Web soporta interacciones directas con otros agentes software utilizando mensajes XML intercambiados mediante protocolos basados en Internet . En [2] define que e xisten múltiples definiciones sobre lo que son los Servicios Web, lo que
muestra su complejidad a la hora de dar una adecuada definición que englobe todo lo que son e implican. Una posible sería hablar de ellos como un conjunto de aplicaciones o de tecnologías con capacidad para interoperar en la Web. Estas aplicaciones o tecnologías intercambian datos entre sí con el objetivo de ofrecer unos servicios. Los proveedores ofrecen sus servicios como procedimientos remotos y los usuarios solicitan un servicio llamando a estos procedimientos a través de la Web. IBM, al respecto considera, que los servicios web son un conjunto de estándares emergentes que habilitan la integración interoperable entre sistemas y procesos de TI heterogéneos. Se puede pensar en aplicaciones web que son auto contenidas y auto descritas y que pueden proporcionar funcionalidad e inter operar alcanzando desde los procesos científicos y de negocios más básicos hasta los más complejos En resumen los servicios web mantienen y proporcionan un mecanismo estándar común para la integración interoperable entre sistemas dispares y la clave de su utilidad es la estandarización. Este mecanismo común para entregar un “servicio” lo hace ideal para implementar un arquitectura orientada a servicios (SOA).[3] Podemos concluir que los servicios web son aplicaciones auto‐contenidas, auto‐descritas que pueden ser publicadas, localizadas e invocadas a través de la web. Una vez
1
W3C World Wide Web Consortium (http://www.w3.org/) es una iniciativa creada en 1994, en la que participan 400 organizaciones, y que pretende que el World Wide Web alcance su máximo potencial desarrollando protocolos comunes que permitan su evolución y aseguren su interoperabilidad.
4
Edwin Valencia Castillo
Estado del Arte de los Servicios Web 2008 desarrolladas, otras aplicaciones (y otros servicios web) pueden descubrirlas e invocarlas respectivamente. Un ejemplo de funcionamiento de los servicios web extraído de [2] se muestran en la Fig. 1., donde un usuario (que juega el papel de cliente dentro de los Servicios Web), a través
de una aplicación, solicita información sobre un viaje que desea realizar haciendo una petición a una agencia de viajes que ofrece sus servicios a través de Internet. La agencia de viajes ofrecerá a su cliente (usuario) la información requerida. Para proporcionar al cliente la información que necesita, esta agencia de viajes solicita a su vez información a otros recursos (otros Servicios Web) en relación con el hotel y la compañía aérea. La agencia de viajes obtendrá información de estos recursos, lo que la convierte a su vez en cliente de esos otros Servicios Web que le van a proporcionar la información solicitada sobre el hotel y la línea aérea. Por último, el usuario realizará el pago del viaje a través de la agencia de viajes que servirá de intermediario entre el usuario y el servicio Web que gestionará el pago.
Figura 1. Los servicios web en funcionamiento[2]
1.2.
CARACTERISTICAS En M. Endrei et.al.[4] identificamos las características principales de los servicios web, los cuales se describen a continuación: Los servicios web son auto‐contenidos: En el lado del cliente, no se requiere ningún software adicional. Un lenguaje de programación con soporte para clientes XML y HTTP, por ejemplo, son suficientes para comenzar. En el lado del servidor, simplemente se requiere un servidor web y un motor de servlets. Es posible para los servicios web, habilitar una aplicación existente sin escribir una línea de código. Los servicios web son auto‐descritos: Ni el cliente ni el servidor conoce o pretende conocer acerca de cualquier cosa además del formato y contenido de los mensajes de peticiones y respuestas (Integración de aplicaciones débilmente acopladas). La definición del formato del mensaje viaja con el mensaje. No se requiere repositorios de metadatos externos o herramientas generadoras de código. •
•
5
Edwin Valencia Castillo
Estado del Arte de los Servicios Web 2008 •
•
•
•
•
•
1.3.
Los servicios web son modulares: Los servicios web son una tecnología para desplegar y proporcionar acceso a funciones del negocio sobre la web; J2EE, CORBA, y otros estándares son tecnologías que permiten implementar estos servicios web. Los servicios web pueden ser publicados, localizados e invocados a través de la web: Los estándares requeridos para hacer esto son: o Simple Object Access Protocol (SOAP), también conocido como protocolo de la arquitectura orientada a servicios, es un RPC basado en XML y un protocolo de mensajería. o Web Service Description Language (WSDL), es una interfaz descriptiva y un protocolo de lenguaje obligatorio. o Universal Description, Discovery, and Integration (UDDI), un mecanismo de registro que se puede usar para buscar descripciones de servicios web. Los servicios web son inter‐operables e independientes del lenguaje: La interacción entre un proveedor de servicio y un solicitante del servicio está diseñado para ser completamente independiente del lenguaje y la plataforma. Esta interacción requiere un documento WSDL para definir la interface y describir el servicio, junto con el protocolo de red (generalmente HTTP). La inter operatibilidad se da, porque el proveedor del servicio y solicitante del servicio no tiene idea de que plataforma o lenguaje está usando el otro. Los servicios web son intrinsecamente abiertos y basados en estándares: XML y HTTP son los fundamentos técnicos para los servicios web. Una gran parte de la tecnología de los servicios web se ha construido usando proyectos open source. Por lo tanto la independencia del vendedor y la inter‐operatibilidad son metas realistas. Los servicios web son dinámicos: Los e‐business dinámicos pueden convertirse en una realidad usando servicios web, porque con UDDI y WSDL, la descripción y descubrimiento de los servicios web pueden ser automatizados. Los servicios web son componibles: Servicios web simples pueden ser agregados a otros más complejos usando técnicas de workflow o llamadas a servicios web de más bajo nivel de un servicio web implementado.
BENEFICIOS J. McGovern et.al.[5] indica que los beneficios de los servicios web en una empresa son: La reusabilidad: La promesa de reutilizar aplicaciones heredadas, base de datos, objetos, y componentes en gran parte no se ha realizado. Los servicios web pueden jugar un rol significativo en mejorar la reusabilidad del software dentro de las organizaciones. Los servicios web pueden envolver aplicaciones heredadas, base de datos, objetos y componentes y exponerlos como servicios reutilizables. La probabilidad que los servicios web mejoren la reusabilidad depende de varios factores como: inter operatibilidad, modularidad, registro central y dependencias de tiempo de compilación reducido. La tecnología interoperable mejora la reutilización. Por ejemplo, si es difícil para una aplicación conectarse a y utilizar un componente, es poco probable que el componente sea reutilizado. Los servicios web se construyen con estándares abiertos, interoperables y ubicuos que maximizan su potencial para la reutilización. La creación de una capa de servicios robusto mejora la reusabilidad, que conduce a un mejor retorno de la inversión. •
6
Edwin Valencia Castillo
Estado del Arte de los Servicios Web 2008 •
Localización transparente: Un entorno de servicios alcanzara una localización
transparente porque la localización se almacena en un registro. Un cliente encuentra y fija un servicio y sin importar donde se localiza el servicio. Por lo tanto, una organización tiene la flexibilidad para mover sus servicios a diferentes maquinas o mover un servicio a un proveedor externo. Es también posible mover código de una plataforma a otra. La arquitectura orientada a servicios requiere que esos servicios soporten un contrato de publicación. La forma que un servicio es implementado es irrelevante, por lo tanto, si llega a ser necesario mover un servicio de la plataforma J2EE a .Net, ningún cambio en los clientes es necesario. "Envolver y sustituir" es un patrón común en un entorno orientado a servicios. Proporciona a la organización la flexibilidad para habilitar servicios en sistemas heredados sin perder la capacidad de los sistemas. Un sistema heredado habilitado por servicios puede sustituir un Nuevo componente o sistema sin requerir cambios en el cliente que usa ese servicio. •
Composición: Los desarrolladores ensamblan aplicaciones de un catalogo preexistente
de servicios reusables. Los servicios no dependen de ninguna aplicación, porque los servicios son independientes, los desarrolladores usaran esos servicios en muchas aplicaciones. El proceso de diseño de interfaces promueve el diseño de interfaces modulares e independientes de la aplicación para las cual fue diseñada inicialmente. Las interfaces diseñadas apropiadamente y la creación de componentes independientes permitirá maximizar este potencial. •
Escalabilidad y Disponibilidad: Un sistema es escalable si la inversión requerida para
agregar más poder de computo es menores que los beneficios adicionales proporcionados. Porque los clientes de un servicio conocen solamente acerca de la interfaz del servicio y no su implementación, cambiar la implementación para hacerla mas escalable y disponible requiere poca inversión. •
Mantienen la inversión en aplicaciones heredadas: Los servicios ayudan a mantener
la inversión en aplicaciones heredadas porque estos especifican solo el método de interacción, y no el método de implementación. Los sistemas heredados pueden ser envueltos en un servicio facade. Este método de crear servicios tiene la ventaja que permiten a las organizaciones reemplazar aplicaciones heredadas sin cambiar la forma en que los clientes acceden al servicio. •
Reducida dependencia del vendedor: Mientras la plataforma usada para construir
aplicaciones soporte estándares de servicios web, el consumidor del servicio es irrelevante. Los servicios web permiten que las organizaciones tomen decisiones sobre que plataforma usar, basado en los meritos de la plataforma más que en el proveedor. Los servicios web representan un cambio importante de poder, del vendedor de hardware y software al consumidor de hardware y software.
1.4.
ELEMENTOS Los autores de [6] y [1], indican que un servicio web es más una idea, un concepto cuya implementación debe respetar una serie de reglas e interfaces para poder ser accedido por cualquier sistema conectado a la red, siempre que disponga de permiso para ello. Fuera de toda implementación, como hemos dicho, existen una serie de partes bien
7
Edwin Valencia Castillo
Estado del Arte de los Servicios Web 2008 diferenciadas que tenemos que tener en cuenta a la hora de implementar y utilizar un servicio web. Estas son los agentes y los servicios, el cliente y el proveedor, la descripción del servicio, la semántica, y por último las personas, la semántica y los agentes. Agentes y Servicios: Un servicio web, constituye una idea o concepto que debe ser implementado por algún agente. El agente es un trozo o pieza de software que implementa esa funcionalidad que realiza el SW. Este agente tiene la peculiaridad de estar capacitado para enviar y recibir mensajes. De esto se desprende, que el agente es el encargado de recibir las peticiones y enviar las respuestas. Sin embargo, el SW es el conjunto abstracto de funcionalidades ofrecidas. El agente será escrito usando algún lenguaje de programación y se ejecutará bajo una plataforma en concreto. Podemos variar este agente según la implementación que deseemos o necesitemos darle. Sin embargo, el SW que implemente el agente será siempre el mismo, es decir, sea cual sea la implementación que demos a un agente para un SW determinado, este último será semánticamente siempre el mismo, lo que variará será el agente. El cliente y el proveedor: El SW pertenece a un propietario que puede ser bien una persona, bien una organización. La entidad proveedora será la persona u organización que desarrolle un agente capaz de soportar un determinado servicio. La entidad que realiza la consulta puede ser también una persona u organización que desea hacer uso del servicio que expone la entidad proveedora. Esta comunicación tipo petición‐ respuesta se realiza entre agentes, ya que en el lado del que consulta también hay implementado un agente que se comunica con el agente de la entidad proveedora, que es el que implementa el servicio o el conjunto de servicios. Para que la comunicación se lleve a cabo de manera correcta, las entidades participantes deben ponerse de acuerdo, tanto en la semántica como en los mecanismos utilizados en el intercambio de mensajes. Descripción del Servicio: El intercambio de mensajes entre las entidades está guiado por un protocolo que éstas deben seguir para que las transacciones lleguen a buen fin. Este protocolo está documentado en la descripción del SW (WSD, Web Service Description). La WSD es una descripción completa del SW, escrito en un lenguaje denominado WSDL[7], y que es inteligible tanto por las máquinas como por las personas, aunque no sin cierta dificultad para estos últimos. En esta descripción se incluyen todos los elementos de un SW susceptibles de ser descritos, tal y como son el formato de los mensajes, los tipos de datos, los protocolos de transporte a través de los cuales el servicio está disponible y los distintos formatos de serialización utilizados para enviar el contenido de los mensajes entre los agentes que llevan a cabo esta comunicación. En esta descripción, también se pueden incluir una o varias direcciones o localizaciones de red o endpoints, mediante las cuales podremos invocar al agente proveedor o podemos obtener información acerca del patrón de comunicación que hay seguir. Semánticas: Definiremos semántica de un SW como el comportamiento que se espera que tenga el mismo. Este comportamiento, se refiere a qué esperamos del SW cuando le enviamos un mensaje de petición. De la misma forma que la sintaxis de un objeto es su estructura, la semántica de un objeto se refleja en las relaciones que éste establece con otros objetos. Mientas que en la sintaxis identificamos diferentes partes, en la semántica identificamos distintos contextos. Esta semántica también puede verse como un contrato entre la entidad que realiza la consulta y la entidad a la que va dirigida la consulta. Este contrato supone un total acuerdo entre las dos entidades, y •
•
•
•
8
Edwin Valencia Castillo
Estado del Arte de los Servicios Web 2008 trata sobre cómo y porqué los agentes que intervienen en la comunicación deberán interactuar. Este acuerdo puede ser explícito o implícito, oral o escrito, inteligible por la máquina o por las personas. Personas, agentes y semánticas: Uno de los propósitos principales de los SW, es el de automatizar procesos que de lo contrario deberían ser llevados a cabo manualmente. El papel que tienen las personas en el uso y en la arquitectura de los SW se puede se puede ver en dos aspectos: Las personas deben estar de acuerdo en la semántica y en la descripción del servicio. Los usuarios de los SW deberán estar implícitos o explícitamente de acuerdo con la semántica y la descripción del servicio al cual dirige las peticiones, y con el que realizan la interacción, mientras que este servicio pertenezca a una persona u organización. La entidad proveedora publicará la semántica y la descripción de su servicio como un contrato del tipo “o lo tomas o lo dejas”, que tendrá que ser aceptado por la entidad que contrate el servicio. Son las personas las que crean los agentes que intervienen en la comunicación, el agente proveedor y el agente que realiza la petición. Los creadores de los agentes deben asegurar que estos cumplen la semántica y la descripción del servicio. Hay varias formas de asegurar esto último: a. Un agente puede ser codificado, de manera que permanentemente implemente la semántica y la descripción de un servicio. b. Podemos codificar el agente, de una manera más general, de forma que dinámicamente le pasemos la descripción y/o la semántica del servicio deseado en ese momento. c. Podemos crear en primer lugar el agente, y luego generar la descripción y/o la semántica del servicio después, a partir del código del agente. En la Figura 2. Se presenta un resumen donde se pueden observar la relación de los elementos citados anteriormente. •
•
•
9
Edwin Valencia Castillo
Estado del Arte de los Servicios Web 2008
Figura 2. Elementos de los servicios web [6] Como se puede ver, la entidad proveedora y la que realiza la petición, se ponen de acuerdo respecto a la descripción del servicio (mediante un documento en WSDL) y la semántica que guiarán la interacción entre los agentes. Cada uno de los agentes, implementa la semántica del servicio, pero desde el punto de vista que le corresponde, es decir, desde el punto de vista del proveedor o del consumidor (el que realiza la petición). Ambos agentes (el solicitante y el proveedor) intercambian mensajes SOAP en nombre de los respectivos propietarios.
II.
ARQUITECTURA DE SERVICIOS WEB La arquitectura de los servicios Web permite que ciertos servicios sean dinámicamente descritos, publicados, descubiertos e invocados en un ambiente de computación distribuida, haciendo uso de los estándares WSDL, UDDI, SOAP y XML respectivamente, permitiendo a los desarrolladores implementar aplicaciones distribuidas, utilizando herramientas muy distintas (heterogéneas) para crear aplicaciones que utilizan una combinación de módulos de software que son llamados desde diversos sistemas distribuidos en regiones geográficas distintas. Los servicios Web son aplicaciones auto‐contenidas y modulares que pueden ser: Descritas mediante un lenguaje de descripción de servicio, como el lenguaje WSDL (Web Service Description Language). [8] •
10
Edwin Valencia Castillo
Estado del Arte de los Servicios Web 2008 •
•
•
•
•
Publicadas, al incluir las descripciones y políticas de uso en algún registro conocido, utilizando el método de registro UDDI (Universal Description, Discovery and Integration).[9] Encontradas, también utilizando el estándar UDDI, al enviar peticiones al registro y recibir los detalles necesarios para la localización y enlace (binding) sobre aquel servicio que se ajusta a los parámetros de la búsqueda. Asociadas, al utilizar la información contenida en la descripción del servicio para crear una instancia de servicio disponible (o Proxy ). Invocadas sobre la red, al utilizar la información contenida en los detalles de enlace de la descripción del servicio; en un documento WSDL. Durante la invocación, como veremos más adelante haremos uso del protocolo SOAP.[10] Compuestas con otros servicios para integrar servicios y aplicaciones nuevas, en lo que constituirá la base de SOA (Service‐Oriented Architecture).
Todos los estándares comentados se basan en XML: los documentos WSDL, son documentos XML; el protocolo SOAP, que permite la comunicación entre servicios, internamente trata información XML en sus dos variantes, por un lado la mensajería SOAP, tratando información XML explícita y por otro lado RPC, que la trata, pero de una manera implícita.
2.1.
COMPONENTES DE LA ARQUITECTURA Los componentes que conforman la arquitectura de servicios web son: 2.1.1. Servicio
La aplicación es publicada para que sea utilizada por todos aquellos solicitantes que cumplan los requisitos especificados por el proveedor de servicios. Evidentemente la implementación se realizará sobre una plataforma accesible en la red. El servicio se describe a través del lenguaje de descripción de servicios, WSDL. Tanto la descripción como las políticas de uso han sido publicadas anteriormente en un registro. 2.1.2. Proveedor de Servicio
Desde el punto de vista comercial, es quien presta el servicio. Desde el punto de vista de la arquitectura, es la plataforma que provee el servicio. 2.1.3. Registro de Servicios
Es un repositorio de descripciones, donde los proveedores publican sus servicios y la forma de accederlos. Permitirá además a los solicitantes realizar distintos tipos de búsquedas, obteniendo de éstas, los detalles necesarios para poder localizarlos y utilizarlos. 2.1.4. Solicitante de Servicios
Desde el punto de vista comercial, la empresa que requiere cierto servicio. Desde el punto de vista de la arquitectura, la aplicación cliente que busca e invoca un servicio.
11
Edwin Valencia Castillo
Estado del Arte de los Servicios Web 2.2.
2008
OPERACIONES DE LA ARQUITECTURA Las operaciones que se pueden realizar con los servicios Web, son las siguientes:
2.2.1. Publicar/Cancelar Un proveedor de servicios podría publicar un determinado servicio comercial (e‐ business) a uno o más registros de servicios, además de, evidentemente, cancelar dicha publicación en un momento dado. 2.2.2. Buscar Los solicitantes de servicios (clientes) podrán interactuar con uno o más registros para descubrir un conjunto de servicios comerciales con los que puedan interactuar para encontrar una solución a sus problemas. 2.2.3. Enlazar (Bind) Los solicitantes de servicios negocian con los proveedores la forma de acceder e invocar a sus servicios comerciales (e‐business). Como se comento, un servicio Web es una colección de funciones que son presentadas como una sola entidad y que es anunciada en la red para ser usada por otros programas. Son por lo tanto, bloques de construcción para crear sistemas distribuidos abiertos. En la figura 3 podemos observar la relación existente entre los componentes y las operaciones de la arquitectura.
Figura 3. Relaciones entre los componentes que conforman la arquitectura de servicios Web Actualmente, las aplicaciones que se están realizando, poseen la capacidad de buscar y seleccionar servicios dinámicamente en tiempo real, basándose en parámetros como el costo, la calidad, o la disponibilidad. Esto supone una gran ventaja a la hora de utilizar sistemas basados en servicios Web, ya que el sistema, de forma automática, elegirá el servicio que más se ajuste a sus necesidades, y por lo tanto el rendimiento del sistema se verá incrementado.
12
Edwin Valencia Castillo
Estado del Arte de los Servicios Web 2008 2.3.
MODELOS ARQUITECTONICOS El W3C Web Service Architecture Working Group[1] definen modelos arquitectónicos como subconjunto coherente de la arquitectura que se centra básicamente en un aspecto concreto dentro de la arquitectura. Cada modelo intenta explicar al máximo el aspecto en el que se ha centrado. Un modelo también debe definir todas las dependencias que pueda presentar con respecto a otros aspectos incluidos en la arquitectura dentro de la cual se ubica. En la Figura 6 mostramos las relaciones existentes entre los distintos modelos mediante una representación gráfica de los mismos.
Figura 4. Metamodelo de la arquitectura de servicios web [1] 2.3.1. El Modelo orientado a mensajes
Este modelo se enfoca en aquellos aspectos relacionados con los mensajes, su estructura, el método de transporte, etc. Este modelo no atiende ni al porqué de los mensajes ni a su significado. El interés principal de este modelo se sitúa en la estructura de los mensajes, las relaciones existentes entre los que envían los mensajes, los que los reciben y otros intermediarios que tengan que procesar también los mensajes para reenviarlos. Relacionados con los mensajes, hay una serie de conceptos que resultan interesantes dentro de la arquitectura y que este modelo comenta, mostrando cual es la relación que guardan unos conceptos con otros, aunque la profundidad con que debe ser tratado se escapa a la profundidad con la que trataremos la cuestión.
13
Edwin Valencia Castillo
Estado del Arte de los Servicios Web 2008 Figura 5. Modelo orientado a mensajes[1] 2.3.2. El Modelo orientado a servicios
Este modelo se centra en aspectos de la arquitectura relacionados con los servicios y las acciones principalmente. El propósito principal de este modelo es explicar las relaciones existentes entre un agente, los servicios que ofrece o implementa y los solicitantes de los servicios. Como es lógico, un agente no podría llevar a cabo la tarea de ofrecer servicios a los clientes si no tuviera la capacidad de enviar y recibir mensajes, pero este modelo no hace referencia los mensajes o al método de transporte de los mismos. El Modelo Orientado a Servicio se construye sobre el Modelo Orientado a Mensajes, pero centrándose en las acciones en lugar de los mensajes. En la figura 8 se muestran algunos conceptos relacionados con este modelo y las relaciones existentes entre ellos.
Figura 6. Modelo orientado a servicios[1] 2.3.3. Modelo orientado a recursos
Este modelo se centra en aquellos aspectos de la arquitectura relacionados con los recursos y el modelo de servicio asociado con la manipulación de los mismos. El Modelo Orientado a Recursos se construye sobre el Modelo Orientado a Servicios, principalmente por el desarrollo del modelo de servicio asociado al recurso y el conjunto de acciones para su manipulación. La función principal de esta parte de la arquitectura es explicar la Web en sí, y cómo se relaciona con los servicios web. Este modelo intenta explicar esto último mostrando como un los recursos son un concepto independiente, y como la manipulación de éstos son solamente una instancia del Modelo de Servicios, sólo que con sus propios servicios y acciones sobre los recursos. A continuación en la figura 9, se muestran algunos conceptos relacionados con este modelo y las relaciones existentes entre ellos.
14
Edwin Valencia Castillo
Estado del Arte de los Servicios Web 2008
Figura 7. Modelo orientado a recursos[1] 2.3.4. Modelo de Políticas
Este modelo se centra en aquellos aspectos de la arquitectura relacionados con las políticas, y por extensión, con la seguridad y la calidad del servicio. El concepto de política es muy simple, es simplemente una restricción sobre el comportamiento de los agentes y los servicios. La seguridad, es básicamente un conjunto de restricciones respecto del comportamiento de las acciones y del acceso a los recursos. De manera similar, la calidad se considera también un tipo de restricción que puede ser aplicada a los servicios. En el Modelo de Políticas, estas restricciones se modelan alrededor de los conceptos de política y sus relaciones con otros elementos de la arquitectura, por ello, el Modelo de Políticas resulta ser un marco de trabajo en el que implementar la seguridad. Sin embargo, existen muchos otros tipos de restricciones y políticas relevantes a los SW, incluyendo restricciones a nivel de aplicación.
Figura 8. Modelo de Políticas[1]
15
Edwin Valencia Castillo
Estado del Arte de los Servicios Web 2008 III.
ESTANDARES Y ESPECIFICACIONES RELACIONADOS CON LOS SERVICIOS WEB En la actualidad existen organizaciones relacionadas con la definición de estándares y especificaciones, estas se encuentran en constante trabajo, buscando que los servicios web sean cada vez más interoperables y seguros. Una breve descripción de estas organizaciones, obtenida de [11] se detalla a continuación: Web Services Interoperability Organization (WS‐I), Es una organización de industria
abierta que busca promover la interoperatibilidad de los servicios web entre plataformas, sistemas operativos y lenguajes de programación. La comunidad agrupa organizaciones líderes en el desarrollo servicios web que ayudan a desarrollar servicios web interoperables proporcionando dirección, practicas recomendadas y soporte de recursos. Específicamente, WS‐I crea, promueve y apoya protocolos genéricos para el intercambio interoperable de mensajes entre los servicios web. World Wide Web Consortium (W3C) fue creada en octubre de 2004 para dirigir el World
Wide Web desarrollando protocolos comunes que promuevan su evolución y aseguren su interoperabilidad. El W3C esta conformado por mas de 350 organizaciones de todo el mundo y ha ganado reconocimiento internacional por sus contribuciones al crecimiento de la web. El W3C esta diseñando la infraestructura, y definiendo la arquitectura y las tecnologías base para los servicios web. Internet Engineering Task Force (IETF) Es una gran comunidad internacional abierta de
diseñadores de red, operadores, vendedores e investigadores referidos con la evolución de la arquitectura de internet y su operación.
Organization for the Advancement of Structured Information Standards (OASIS) Es un
consorcio internacional sin fines de lucro que conduce el desarrollo, convergencia y adopción de estándares e‐business. El consorcio produce más estándares de servicios web que cualquier otra organización junto con estándares para seguridad, e‐business, y esfuerzos de estandarización en el sector público y mercados de aplicación especifica. Fundado en 1993, OASIS tiene más de 4000 participantes, representando a más de 600 organizaciones y miembros individuales en 100 países. A continuación se muestra el núcleo de estándares para los servicios web. La separación entre capas indica las dependencias aproximadas entre estas.
16
Edwin Valencia Castillo
Estado del Arte de los Servicios Web 2008
Figura 9. Pila de servicios web[1] •
•
•
•
17
Comunications ó transporte: La especificación de los estándares de servicios web (SOAP y WSDL es esencialmente independiente del medio de transporte. La
interoperabilidad garantiza a HTTP como protocolo usado para transmitir mensajes SOAP, lo que no quita que se pueda utilizar cualquier otro protocolo para la mensajería. Mensajería: SOAP está en el núcleo de la capa de la mensajería en los servicios web. SOAP define un modelo de codificación extensible, basado en XML. La importancia de SOAP es que brinda el marco para construir la operabilidad on the wire en tiempo de ejecución. La capa de mensajería también está diseñado para convivir con otros protocolos de mensajería no‐XML Descripciones: Al ser débilmente acoplado, el modelo orientado a servicios requiere que se expliciten las capacidades y los requisitos del servicio ofrecido. Se da soporte a la descripción de servicios en dos niveles. La definición funcional (qué hace el servicio) en la forma de lenguaje de definición de interfaces (basado en XML) lo proporciona WSDL. Éste describe los protocolos específicos de transporte y el modelo de mensajería a utilizar para interactuar con el mismo. Las descripciones sobre los requisitos de calidad del servicio (Como se utiliza el servicio) se ofrecen en forma de " políticas de servicio web", codificando información tal como los requisitos de seguridad del servicio, los protocolos fiables de mensajería a seguir o los requisitos de privacidad. La especificación WS‐Policy define un lenguaje simple para codificar estos requisitos. Procesos: Esta capa incluye procesos tales como el de Descubrimiento, la coordinación y la negociación de la interacción. El primero nos brinda la capacidad de descubrir dinámicamente nuestros servicios web, de vincularlos y de interactuar con ellos. La especificación UDDI (Universal Description, Discovery and Integration) define el servicio y permite el descubrimiento de servicios basados en su función y capacidades declaradas, pudiéndose, en los entornos más dinámicos, definir contratos que regulen la interacción entre dos socios de servicios respecto a características de la prestación del servicio, consideraciones financieras, legales, etc. Esto se puede especificar en un Edwin Valencia Castillo
Estado del Arte de los Servicios Web 2008 formato legible por la máquina. La capacidad de negociar estos contratos dinámicamente será de vital importancia para llevar a cabo la visión completa del paradigma de la orientación a servicios. Asimismo en [3], podemos encontrar una representación grafica y agrupación de todos los estándares y especificaciones.
Figura 10. Estándares y especificaciones relacionados a los servicios web[3] La agrupación de estos estándares, las cuales se obtuvieron de [3] y [11] , se describe a continuación: •
Transporte
BEEP, el protocolo extensible de intercambio de bloques (Blocks Extensible Exchange Protocol ‐ BEEP), referido generalmente como BXXP, es un framework para construir protocolos de aplicación. Ha sido estandarizado por el IETF (Internet Engineering Task Force) y es para los protocolos de internet como XML lo es para los datos. •
Mensajes
Estas especificaciones y estándares de mensajes intentan proporcionar un framework para el intercambio de información en un entorno distribuido y descentralizado. SOAP 1.1 (Note) SOAP 1.2 (Specification) Web Services Addressing Web Services Notification (WS‐BrokeredNotification, WS‐BaseNotification, WS‐Topics Web Services Attachments Profile 1.0 MTOM Serialization Policy Assertion (WS‐MTOMPolicy) Version 1.0 •
Descripción y descubrimiento
Los servicios web son significativos solo si los usuarios potenciales pueden encontrar información suficiente para permitir su ejecución. El enfoque de estos estándares y especificaciones es la definición de un conjunto de servicios que apoyen la descripción y descubrimiento de los negocios, organizaciones y otros proveedores de servicios web; los servicios web que hacen disponibles y las interfaces técnicas que se pueden utilizar para tener acceso a estos servicios. UDDI 3.0 WSDL 1.1 (Note) WSDL 1.2 (Working draft)
18
Edwin Valencia Castillo
Estado del Arte de los Servicios Web 2008 WSDL 2.0 (Working Group) Web Services Semantics ‐‐ WSDL‐S Web Services Metadata Exchange Web Services Policy Assertions Language Web Services Policy Attachment Web Services Policy Framework Web Services Resource Framework •
Confiabilidad
No es posible solucionar aspectos del negocio si los participantes no pueden estar seguros de la culminación exitosa del intercambio de mensajes. La mensajería confiable que permite que los mensajes sean entregados confiablemente entre aplicaciones distribuidas en presencia de componentes software, sistemas o fallas de la red, es por lo tanto critico en los servicios web. Web Services Reliable Messaging WS‐RM Policy Assertion •
Transacciones
Las transacciones son un concepto fundamental en la construcción de aplicaciones distribuidas confiables. Un entorno de servicios web requiere un comportamiento de coordinación proporcionado por un mecanismo de transacción tradicional para controlar las operaciones y el resultado de una aplicación. Web Services Atomic Transaction Web Services Business Activity Web Services Coordination •
Seguridad
Usando estas especificaciones de seguridad, las aplicaciones pueden garantizar una comunicación segura diseñada para trabajar con un framework de servicios web en general. Web Services Federation Language WS‐Federation: Active Requester Profile WS‐Federation: Passive Requester Profile Web Services Provisioning Web Services Secure Conversation Language Web Services Security 1.0 Web Services Security Addendum WS‐Security Kerberos Binding Web Services Security Policy Web Services Trust Security Assertion Markup Language (SAML) •
Procesos de negocio
Un proceso de negocio especifica un orden de ejecución potencial de operaciones de una colección de servicios web, los datos compartidos entre estos servicios web, que socios están involucrados y como ellos están involucrados en el proceso del negocio, junto con el manejo de excepciones para las colecciones de servicios web y otros
19
Edwin Valencia Castillo
Estado del Arte de los Servicios Web 2008 aspectos involucrados como servicios múltiples y organizaciones participantes. BPEL especifica el proceso de negocio y como los servicios web se relacionan. WS‐BPEL Extension for People Business Process Execution Language for Web Services V1.1 •
Administración
La administración de servicios web es definida como un conjunto de capacidades para descubrir la existencia, disponibilidad, funcionalidad, rendimiento, uso, asi como el control y configuración de un servicio web con la arquitectura de servicios web. Pues los servicios web llegan influyentes y críticos para la operación del negocio, la tarea de administrarlos e implementarlos es imperativa al éxito de las operaciones del negocio. Web Services Distributed Management Web Services Manageability Web Services Manageability ‐‐ Concepts Web Services Manageability ‐‐ Representation WS‐ResourceTransfer Web Services Service Registry and Repository En la siguiente figura se presenta todos los estándares y especificaciones según [11]
Figura No. 11. Pila de estándares y especificaciones de los servicios web[11]
20
Edwin Valencia Castillo
Estado del Arte de los Servicios Web 2008 En los párrafos siguientes presentaremos un breve resumen de los principales estándares y especificaciones de los servicios web y sus aspectos principales.
3.1.
SOAP (Simple Object Access Protocol) El estándar SOAP (en su versión actual 1.2, recomendado por W3C en su segunda edición en el 2007[10]) define un protocolo que da soporte a la interacción (datos + funcionalidad) entre aplicaciones en entornos distribuidos y heterogéneos, y es interoperable, es decir, neutral a la plataforma, lenguajes de programación, independiente del hardware y protocolos. Funciona sobre la infraestructura (estándares) existentes en Internet. SOAP define cómo organizar la información XML de una manera estructurada y tipada para intercambiarla entre los distintos sistemas. El protocolo SOAP simplifica el acceso a los objetos, permitiendo a las aplicaciones invocar métodos de objetos o funciones, que residen en sistemas remotos. En [12] se indica que SOAP es fundamentalmente un paradigma de intercambio de mensajes en un sólo sentido, sin estado, pero las aplicaciones pueden crear patrones de interacción más complejos (por ejemplo, petición/respuesta, petición/respuestas múltiples, etc.) combinando tales intercambios de un solo sentido con características proporcionadas por el protocolo utilizado y/o información específica de la aplicación en cuestión. SOAP no interfiere en la semántica de cualesquiera datos específicos de aplicación que comunica, ni tampoco en asuntos tales como en enrutamiento de mensajes SOAP, transferencia de datos fiables, cortafuegos que atraviesa, etc. No obstante, SOAP proporciona el marco de trabajo por el que la información de aplicaciones específicas puede comunicarse de forma extensible. También, SOAP proporciona una descripción completa de las acciones que debe realizar un nodo SOAP al recibir un mensaje SOAP. En [13], detalla que SOAP especifica: Un formato de mensaje para una comunidad unidireccional, describiendo cómo se empaqueta la información en documentos XML. Un conjunto de convenciones para usar mensajes SOAP, para implementar el patrón de interacción RPC, definiendo cómo los clientes pueden invocar un procedimiento remoto enviando un mensaje SOAP y cómo los servicios pueden responder enviando otro mensaje al llamador. Un conjunto de reglas que una entidad que procesa mensajes SOAP debe seguir, definiendo en particular los elementos XML que una entidad debe leer y entender, así como las acciones que deben tomar si no entienden el contenido (reglas de codificación de datos). Una descripción de cómo se debe transportar un mensaje SOAP sobre HTTP y SNMP. Se definirán bindings a otros protocolos de transporte en futuras versiones de la especificación. •
•
•
•
Los mensajes SOAP son fundamentalmente mensajes en una dirección, desde un “emisor” (cliente) hacia un “receptor” (servidor), y las comunicaciones son del tipo request/response. Todos los mensajes son documentos XML con su propio esquema, que incluye sus propios espacios de nombres (namespaces), elementos y atributos.
21
Edwin Valencia Castillo
Estado del Arte de los Servicios Web 2008 SOAP define dos namespaces: envelope y encoding. Como característica destacable, podemos decir que no puede tener DTD asociados. Los mensajes SOAP constan de tres secciones (ver figura 4): envelope, header y body . Envelope (envoltura): Es el elemento raíz del mensaje para describir su contenido y la forma de procesarlo. Header (encabezado): información de identificación del contenido. Body(cuerpo): es el contenido del mensaje. •
• •
Figura 12. Secciones de un mensaje SOAP Se pueden realizar extensiones al protocolo; esto es posible gracias a la adicción de módulos de funcionalidad. Este enfoque permite a los desarrolladores usar los módulos y funcionalidades que necesiten, sin la necesidad de tener que implementar la totalidad de estos. En pocas palabras, el protocolo puede ser extensible. Algunas de las extensiones más importantes que se pueden realizar son las que se muestran a continuación: Attachments: Hace referencia a la posibilidad de incluir un documento no XML, o archivo binario, enviar documentos de fax, imágenes de medicina, dibujos de ingeniería, o cualquier otro tipo de imágenes, codificadas en Base64. Routing/Intermediaries: Relacionadas con el proceso de encaminar mensajes SOAP a través de intermediarios. Este mecanismo ofrece la posibilidad de agregar varios servicios Web y ofrecerlos como parte de un paquete. Esto es una tarea que permite hacer los servicios Web escalables a través del direccionamiento, incluso, hacia múltiples servidores. Reliable Messaging: Determina cuanto tiempo espera un servidor cuando envía un mensaje y espera por la respuesta. Security: Esta extensión nos permitirá dar un marco de seguridad a la comunicación. Algunos de los aspectos podrían ser aplicar SSL, firma digital, etc. Mediante XML Signature podemos proporcionar integridad, autenticación de mensajes, y/o servicios de autenticación de firmas. Quality of Service (QoS): Es una medida para calificar la calidad del servicio, determinando la usabilidad y utilidad del servicio. Context/Privacy: Referencia a los mecanismos para guardar el contexto y la privacidad del entorno de los usuarios. •
•
•
•
•
•
22
Edwin Valencia Castillo
Estado del Arte de los Servicios Web 2008 •
Transaction Support: Permite que un grupo de operaciones o acciones se comporten
como si fueran una simple unidad (o todo falla o todo es un éxito). En cuanto al rendimiento de los mensajes de SOAP utilizando HTTP y XML, comparado con el rendimiento de mensajes binarios utilizados por CORBA, DCOM y RMI, se puede afirmar que en el caso de los últimos, tanto el destinatario y remitente tienen conocimiento completo del contenido del mensaje y no codifican meta información como los nombres o tipo de argumentos. Quizás este método sea eficiente, pero dificulta a los intermediarios el procesamiento de mensajes. Y debido a que cada sistema utiliza una codificación binaria distinta, dificulta la construcción de sistemas interoperables. Dado que SOAP utiliza XML para codificar mensajes, es relativamente sencillo procesar los mensajes en cada paso del proceso de llamada. Además, la facilidad de depuración de mensajes SOAP permite la convergencia rápida de las diversas implementaciones de SOAP, lo cual es importante en la interoperabilidad a gran escala.
3.2.
WSDL (Web Service Description Language) El WSDL (Web Service Description Language)[8], creado originalmente por IBM, Microsoft y Ariba. Tiene un rol y un propósito similar al de los IDL (Interface Definition Language) de las plataformas middleware es decir, ofrecer un software de conectividad que permite ofrecer un conjunto de servicios que hacen posible el funcionamiento de aplicaciones distribuidas sobre plataformas heterogéneas. Un archivo WSDL es un documento XML que describe los servicios Web, en particular sus interfaces. Como característica que lo diferencia de los IDL, es que WSDL debe definir los mecanismos de acceso (protocolos) a los servicios Web. Otra característica diferenciadora es la necesidad de definir (en la especificación) la localización del servicio (puntos finales). La separación de interfaces y enlaces de protocolos, y la necesidad de incluir información de localización permite la definición de especificaciones modulares. WSDL permite definir interfaces más complejas y expresivas; permitiendo definiciones de interacciones asíncronas y diferentes paradigmas de interacción, y la posibilidad de combinar o agrupar operaciones. En la figura 3, se muestra un diagrama con la arquitectura de los sistemas basados en servicios Web, en el que se representan los estándares descritos. WSDL es un formato XML que describe los servicios de red como un conjunto de endpoints que procesan mensajes contenedores de información orientada tanto a documentos como a procedimientos. Las operaciones y los mensajes se describen de forma abstracta, y después se enlazan a un protocolo de red y a un formato de mensaje concreto para definir un endpoint de red. Los endpoints concretos relacionados se combinan en endpoints abstractos (servicios). El lenguaje WSDL es extensible, lo que permite la descripción de endpoints de red y sus mensajes, independientemente de los formatos de los mensajes o protocolos de red utilizados para comunicarse. El documento WSDL de un servicio proporciona dos piezas de información básicas: (1) una parte o interface abstracta (independiente de la aplicación) y (2) una parte específica, que
23
Edwin Valencia Castillo
Estado del Arte de los Servicios Web
2008
define los enlaces a protocolos e información de los puntos finales de acceso al servicio. Ver figura 5.
Figura 13 Estructura de un documento WSDL La parte abstracta está compuesta por: Definiciones de port types: análogos a los interfaces en IDL. Cada port type es una colección lógica de operations. Operations: Cada operation define un intercambio simple de mensajes. Message: Un message es una unidad de comunicación que representa un intercambio de datos en una única transmisión lógica. Types: Un sistema de tipos (types) usados por las operations (por defecto XML Schema). •
• •
•
La parte específica está compuesta por: Definiciones de Bindings: se especifica la codificación de los mensajes, y los enlaces a protocolos de todas las operaciones y mensajes definida en un port type. Definiciones de Ports: se especifica en qué dirección (URI) se puede acceder a la implementación del port type. Definen un punto final (lugar de la red) donde está el servicio. Definiciones de Services: definen una agrupación de Ports. •
•
•
Esta es la forma que tiene WSDL de describir los servicios Web, en términos de los mensajes que acepta y genera. Actúa como contrato entre un consumidor (cliente) y dicho servicio. WSDL puede describir puntos finales y sus operaciones sin especificar el formato de los mensajes o los protocolos de red (SOAP, HTTP‐GET/POST y MIME) a los cuales el punto final está ligado. El lenguaje de descripción de servicios Web es, por lo tanto, el equivalente a un resumen diseñado en XML, en el cual se describen los servicios Web, indicando dónde se ubican y la forma de invocarlos. A continuación se muestra un ejemplo de documento WSDL.
24
Edwin Valencia Castillo
Estado del Arte de los Servicios Web 2008 3.3.
UDDI (Universal Description Discovery and Integration) El UDDI[9], es un directorio que contiene un registro/repositorio de descripciones de servicios Web. Este estándar permite a las empresas registrarse en un tipo de directorio de Internet que les ayuda a anunciar sus servicios, de tal forma que el resto de compañías puedan localizar sus servicios y realizar transacciones en la Web. El proceso de registro y consultas se realiza utilizando mecanismos basados en XML y HTTP(S). Por lo tanto, la especificación UDDI tiene dos objetivos esenciales, en primer lugar servir de soporte a los desarrolladores para encontrar información sobre servicios Web y poder construir clientes; y por otro lado, facilitar el enlace dinámico de servicios Web, permitiendo consultar referencias y acceder a servicios de interés. Siempre ha sido un reto la comunicación entre los negocios a nivel de aplicaciones, dada la enorme cantidad de plataformas, herramientas, mecanismos y procesos que cada cual utiliza. XML se presenta como la solución para el intercambio de datos de una forma transparente. También, la evolución de protocolos como SOAP, ya comentado anteriormente, proporciona una plataforma para el intercambio de servicios sobre la red. Si el mecanismo de comunicación entre las plataformas es el XML, y la forma de comunicación es SOAP, la cuestión que se plantea es cómo encontrar a las organizaciones que proporcionan servicios con los que comunicarse. La respuesta es el UDDI. UDDI, aunque fue creado originalmente por IBM, Microsoft y Ariba, desde su versión 3, la organización OASIS[14] se encarga de su mantenimiento. UDDI se concibió como un registro de negocio, es decir un servicio de directorio y un nombrado sofisticado conjuntamente. Especifica un marco para describir y descubrir servicios Web. UDDI define estructuras de datos y API’s para publicar descripciones de servicios en el registro, y métodos de consulta para buscar descripciones publicadas. Las API’s de UDDI están especificadas con WSDL y con SOAP Binding, lo que permite acceder a ellas como servicios Web. La especificación UDDI tiene dos objetivos esenciales: (1) ser un soporte a los desarrolladores para encontrar información sobre servicios Web y poder construir aplicaciones clientes que los invoquen, y (2) facilitar el enlace dinámico de servicios Web, permitiendo consultar referencias y acceder a servicios de interés. La información en un registro UDDI se almacena en ficheros XML con una estructura jerárquica. Los elementos básicos de esta estructura son: BusinessEntity: Es el elemento “top‐level ”, describe un negocio o una entidad que ha registrado un servicio en UDDI. BusinessService: Describe un servicio Web que ha sido expuesto por una entidad de negocio, soporta el nombrado de un servicio Web y lo asocia con una entidad de negocio y con la información de binding. Soporta la asignación de categorías al servicio Web (industria, productos, códigos geográficos, etc.). BindingTemplate: Describe la información técnica necesaria para enlazar con un servicio Web en particular. Este elemento soporta el nombrado de un servicio Web y su asociación con una entidad de negocio e información de binding. La información de binding se describe como un punto de acceso que posee un atributo llamado UrlType utilizado para especificar los siete puntos de entrada: mailto, http, https, ftp, fax, phone, other . •
•
•
25
Edwin Valencia Castillo
Estado del Arte de los Servicios Web •
2008
tModel: Estructura de metadatos genérica para representar cualquier concepto o construcción (definiciones de protocolos, ficheros WSDL, XML Schemas, espacios de nombres, esquemas de categorías, etc.).
Figura 14. Estructura de datos UDDI Conceptualmente, la información proporcionada por una organización que ofrece servicios Web en un registro UDDI consta de tres componentes: •
•
•
3.4.
Sección Blanca: Es muy similar a la información que aparece en un directorio telefónico, que incluye dirección, contacto y otros identificadores conocidos. Sección Amarilla: Es muy similar a su equivalente telefónico, e incluye categorías de catalogación industrial tradicionales, ubicación geográfica, etc. Mediante el uso de códigos y claves predeterminadas, los proveedores de servicios se pueden registrar y así facilitar a pos‐potenciales usuarios de sus servicios la búsqueda usando estos índices de clasificación. Sección Verde: Contiene la información técnica de los servicios ofrecidos por los proveedores. Se incluyen referencias de especificaciones de servicios Web así como información complementaria para los mecanismos diversos de búsqueda basados en URL.
WS-SECURITY Esta especificación maneja el cifrado y firmas digitales, permitiendo crear una aplicación en la cual los mensajes no puedan ser escuchados ilegalmente y que él no repudio sea posible. Describe ampliaciones para los mensajes SOAP proporcionando calidad de protección con integridad de mensajes, confidencialidad de mensajes y autenticación simple de mensajes. La especificación proporciona un conjunto de mecanismos para ayudar a desarrolladores de servicios web a asegurar el intercambio de mensajes SOAP. Estos mecanismos básicos de seguridad pueden combinarse de varias formas para acomodar una variedad de modelos de seguridad usando una variedad de tecnologías de cifrado. Estos modelos de seguridad se describen en [15] y se resumen a continuación: Modelo de Seguridad de Mensajes: Especifica un modelo de seguridad de mensajes abstracto en términos de seguridad de tokens combinado con firmas digitales para •
26
Edwin Valencia Castillo
Estado del Arte de los Servicios Web 2008
•
•
proteger y autenticar mensajes SOAP. Los tokens de seguridad afirman validez y pueden ser usados para afirmar el enlace entre los secretos de autenticación o claves y las identidades de seguridad. Protección de Mensajes: Proteger el contenido del mensaje de ser divulgado (confidencialidad) o modificado sin detección (integridad) son las principales preocupaciones de la seguridad. Esta especificación provee un medio para proteger un mensaje por cifrado y/o firma digital de un cuerpo, una cabecera o cualquier combinación de ellos (o partes de ellos). La integridad de los mensajes está provisto por una firma XML en conjunto con tokens de seguridad que aseguran que las modificaciones a mensajes sean detectados. Los mecanismos de seguridad son diseñados para soportar múltiples firmas, potencialmente por múltiples actores/roles SOAP y para son extensibles para soportar formatos de firma adicional. Demandas pérdidas o invalidas: Un recipiente de mensajes debe rechazar mensajes conteniendo firmas inválidas, demandas de mensajes perdidos o mensajes que tienen valores inaceptables. Dichos mensajes son no autorizados (o malformados). Esta especificación provee una forma flexible para que el productor de mensajes haga una demanda sobre las propiedades de seguridad asociando cero o más tokens de seguridad con el mensaje.
Hay tres problemas principales involucrados en la seguridad del intercambio de mensajes SOAP, y los WS‐Security proveen respuestas para todo ellos, pero no directamente. Es de hecho, una especificación que habla no sobre cómo proteger el mensaje, sino como permitir al receptor que conozca cómo has protegido el mensaje. El primer problema es identificar y autenticar el cliente. Porque hay muchas formas diferentes de crear tokens de seguridad, WS‐security no especifica un medio en particular, pero define algo como tokens de seguridad diferentes deben ser transferidos dentro de mensajes SOAP. Es decir, se deja al receptor conocer como extraer tokens de seguridad del mensaje para procesar. El segundo problema es asegurar la integridad del mensaje. WS‐Security usa firmas digitales para eso, empleando la especificación de firmas XML mas que inventando algo nuevo. La firma XML es una recomendación del W3C que provee un mecanismo para firmar digitalmente documentos XML. El tercer problema está en mantener el mensaje seguro y evitar que sea escuchado ilegalmente mientras esta en tránsito. Una vez más, WS‐Security emplea otro estándar del W3C, el cifrado XML, que proporciona un mecanismo para cifrar documentos XML. WS‐Security define como agregar firmas XML y cabeceras de cifrado XML para mensajes SOAP. En la siguiente figura se muestra como se integra WS‐Security a SOAP.
27
Edwin Valencia Castillo
Estado del Arte de los Servicios Web 2008
Figura 15. WS‐Security integrado con SOAP
3.5.
WS-POLICY
Esta especificación amplia el WS‐Security, permitiendo detallar más específicamente cómo y por quien un servicio puede ser usado. El framework WS‐Policicy, es una especificación que permite a un servicio web tener un conjunto de reglas que deben ser resueltas, o consumidas. Los autores de clientes de servicios web deben entonces estudiar la información de las políticas para ver si pueden o no adherirse a estas políticas. Así, un cliente no podría ser inscrito para acceder simplemente a un servicio web que tenga una política que requiere que todos los mensajes sean encriptados o firmados de alguna manera. El W3C describe el modelo de SW‐POLICY en [16], el cual consta de : Policy Assertion (Política de aserción) una política de aserción identifica un comportamiento que es un requerimiento (o capacidad) de un tema, indica semántica de dominio especifico (por ejemplo, seguridad, transacciones) y esperan ser definidas en especificaciones separadas y de dominio especifico. •
•
Policy Alternative (Política alternativa) una política alternativa es una construcción
lógica que representa una colección potencialmente vacía de políticas de aserción. Una política sin aserciones indica sin comportamiento. Una política con una o más aserciones indica comportamiento implicado para aquellas y solo aquellas aserciones.
•
28
El vocabulario de una política alternativa es un conjunto de todos los tipos de aserciones dentro de la alternativa. El vocabulario de una política es un conjunto de todos los tipos de aserciones usados en todas las políticas alternativas en la política. Una aserción cuyo tipo es parte del vocabulario de una política pero o está incluido en una alternativa es explícitamente prohibido por la alternativa. Las aserciones dentro de una alternativa no son ordenadas, y los aspectos como el orden en la cual es comportamiento es aplicado a un sujeto están mas allá del alcance de esta especificación. Política: A nivel abstracto una política es una colección potencialmente vacía de políticas alternativas. Una política con cero alternativas no contiene opciones; una Edwin Valencia Castillo
Estado del Arte de los Servicios Web 2008
•
3.6.
política con una o más alternativas indica selección en requerimientos (o capacidades) dentro de la política. Las alternativas no son ordenadas, y así los aspectos tales como preferencias entre alternativas en un contexto dato van más allá de esta especificación. Web services: Aplicado en el modelo de servicios web, una política es usada para transportar condiciones en una interacción entre dos servicios web. La satisfacción de aserciones en la política usualmente da como resultado un comportamiento que refleja estas condiciones. Típicamente el proveedor de un servicio web expone una política para transportar condiciones, bajo las cuales proporciona el servicio. Un solicitante puede usar esta política para decidir si utiliza o no el servicio. Un solicitante puede escoger cualquier alternativa puesto que cada una, es una configuración válida para la interacción con el servicio, pero un solicitante debe escoger solo una simple alternativa para una interacción con un servicio puesto que cada uno representa una configuración alternativa.
WS-I
Aunque los servicios web se supone fueron diseñados para la interoperatibilidad, en la actualidad hay bastante flexibilidad en las especificaciones, y que las interpretaciones entre diferentes implementaciones puede causar problemas. WS‐I proporciona un conjunto de estándares y prácticas para prevenir estos problemas, así como pruebas estandarizadas para verificar si hay problemas. El primer desafío es comprender el problema de la interoperatibilidad y su importancia en el mundo de los servicios web. Los servicios web hoy son construidos usando una compleja familia de tecnologías relacionadas y estándares, que generan muchas fuentes de temas relacionados con la interoperatibilidad. El WS‐I definido en el Basic Profile Version 1.0 por el Web Service Interoperatibily Organización [17], consiste de un conjunto de especificaciones de servicios web no propietarios, junto con aclaraciones y enmiendas a esas especificaciones que promueven la interoperatibilidad.
3.7.
WS-BPEL
Es un lenguaje de composición de Servicios Web Orientado a Procesos. Se basa en WSDL y de hecho un proceso WS‐BPEL puede ser expuesto a través de su propio WSDL y por tanto ser invocado como cualquier otro Servicio Web (permitiendo la reutilización de los mismos). Nació como combinación de WSFL (Web Service Flow Language de IBM, orientado a grafos y basado en el control de los links entre tareas) y XLANG (Web Services for Business Process Design de Microsoft, basado en un control de flujos con secuencias, condiciones, bucles, etc…) y ha evolucionado adquiriendo lo mejor de cada uno e intentando evitar las malas prácticas de los mismos (debido a que el paradigma de utilización de ambos es distinto y a veces de lugar a situaciones de construcción sobrelapadas). WS‐BPEL define un conjunto de tareas básicas para la composición de servicios web: Tareas de Invocación (Invoke): Invocación de operaciones one‐way o request‐ response en un servicio web. Tareas de Recepción (Receive): Permite el bloqueo de un proceso a la espera de llegada de un mensaje. •
•
29
Edwin Valencia Castillo
Estado del Arte de los Servicios Web 2008 •
• • • •
Tareas de Respuesta (Response): Permite enviar un mensaje en respuesta a un
mensaje recibido previamente. Tareas de Espera (Wait): Permite la espera durante un tiempo del proceso. Tareas de Asignación (Assign): Permite copiar datos de un lugar a otro. Tareas de Lanzamiento (Throw): Permite indicar que ha ocurrido un error. Tareas de Finalización (End): Permite finalizar la orquestación de la instancia en curso.
Además, las tareas estructuradas son utilizadas para combinar las primitivas en otras más complejas: Tareas secuenciales (sequence): Define un orden secuencial de tareas. Tareas de decisión (switch): Permite seleccionar un camino en particular en base a una condición. Tareas de elección: Permite bloquear y esperar la llegada de un mensaje o establecer un tiempo límite de espera (timeout). Cuando uno de los eventos ocurre, se ejecutan las tareas designadas. Tarea repetitiva (While): Permite repetir un grupo de tareas mientras se cumpla una determinada condición. Tareas paralelas: Permite paralelizar la ejecución de cierto grupo de tareas. • •
•
•
•
WS‐BPEL trata todos los estados como una colección de tipos de mensajes WSDL. Esa colección de mensajes que constituyen un estado es lo que se llama contenedor. Los mensajes de un contenedor pueden ser los enviados o recibidos con clientes o servicios externos; incluso los utilizados internamente por el proceso para computación temporal de los mismos. Asimismo, la comunicación se define a través de los PortType de los WSDL. WS‐BPEL sostiene la idea de un contenedor para cada tarea en el flujo definido, cada uno de los cuales tiene una definición de esquema. Así, un mensaje se corresponde a un contenedor, que básicamente es un servicio web con información adicional sobre como procesarlo, posibles pre‐condiciones y post‐condiciones. De modo gráfico, un proceso definido en WS‐BPEL tendría la siguiente forma:
Figura 16 Proceso WS‐BPEL
30
Edwin Valencia Castillo
Estado del Arte de los Servicios Web 2008 Todos los accesos a datos y manejos de los mismos en WS‐BPEL es definido utilizando estándares como XPath y XSLT, además de basarse en los contratos de servicios establecidos por medio de los WSDL. Durante la ejecución de un proceso se pueden establecer más de una conversación con servicios externos, por lo que es necesario establecer mecanismos a nivel de aplicación para corresponder los mensajes y conversaciones con las instancias de procesos que sean objetos de los mismos. Para ello, WS‐BPEL ofrece lo que se conoce como “Correlation Sets” o Grupos de Correlaciones. Estos son conjuntos de propiedades, que juntos sirven para definir una conversación a nivel de aplicación dentro de una instancia de proceso. Básicamente son identificadores únicos de instancias de proceso, que permite saber en todo momento que instancia corresponde a qué mensaje recibido o enviado a través del mismo. WS‐BPEL puede ser utilizado tanto para orquestación de servicios (llamadas a procesos ejecutables; entendiendo como tal las llamadas a servicios y la especificación de como se llevan a cabo) como para coreografía de servicios (llamadas a procesos abstractos; entendiendo como tal los mensajes públicos a intercambiar entre dos o más partes). Por lo general, la implementación de WS‐BPEL varía según el fabricante y de hecho algunos lo interpretan como un Script XML que puede ser ejecutado con un motor específico; mientras que otros lo interpretan como un lenguaje de intercambio. La última especificación, la 2.0 incluye nuevas características como inicialización de variables, transformación XSLT de variables, acceso XPath a datos de variables, etc. Esta especificación ha sido aprobada el 31/01/2007 por OASIS y se la documentación de este estándar está disponible en [18].
IV.
REST UNA PROPUESTA ALTERNATIVA A SOAP En los últimos años se ha popularizado un estilo de arquitectura Software conocido como REST (Representational State Transfer). Este nuevo estilo ha supuesto una nueva opción de estilo de uso de los Servicios Web. Los Servicios Web basados en REST intentan emular al protocolo HTTP o protocolos similares mediante la restricción de establecer la interfaz a un conjunto conocido de operaciones estándar (por ejemplo GET, PUT,…). Por tanto, este estilo se centra más en interactuar con recursos con estado, que con mensajes y operaciones. Un ejemplo de utilización de SOAP y REST es Amazon, quien posee ambos estilos de uso de sus servicios Web. Pero el 85% de sus clientes prefieren la interfaz REST. A pesar de la promoción que las empresas han invertido para ensalzar a SOAP, parece que es evidente que los desarrolladores prefieren, en algunos casos, la aproximación más sencilla, REST.
4.1.
DEFINICION El autor de [19] indica que REST es un estilo de arquitectura de software para sistemas hipermedias distribuidos tales como la Web. El término fue introducido en la tesis doctoral de Roy Fielding[20] en 2000, quien es uno de los principales autores de la especificación de HTTP. En realidad, REST se refiere estrictamente a una colección de principios para el diseño de arquitecturas en red. Estos principios resumen como los recursos son definidos y diseccionados. El término frecuentemente es utilizado en el sentido de describir a cualquier interfaz que transmite datos específicos de un domino sobre HTTP sin una capa
31
Edwin Valencia Castillo
Estado del Arte de los Servicios Web 2008 adicional, como hace SOAP. Estos dos significados pueden chocar o incluso solaparse. Es posible diseñar un sistema software de gran tamaño de acuerdo con la arquitectura propuesta por Fielding sin utilizar HTTP o sin interactuar con la Web. Así como también es posible diseñar una simple interfaz XML+HTTP que no sigue los principios REST, y en cambio seguir un modelo RPC. Cabe destacar que REST no es un estándar, ya que es tan solo un estilo de arquitectura. Aunque REST no es un estándar, está basado en los estándares HTTP, URL, Representación de los recursos (XML/HTML/GIF/JPEG/…) y Tipos MIME (text/xml, text/html, …).
4.2.
PRINCIPIOS Los objetivos de este estilo de arquitectura se listan a continuación: •
Escalabilidad de la interacción con los componentes. La Web ha crecido
exponencialmente sin degradar su rendimiento. Una prueba de ellos es la variedad de clientes que pueden acceder a través de la Web: estaciones de trabajo, sistemas industriales, dispositivos móviles,… •
Generalidad de interfaces. Gracias al protocolo HTTP, cualquier cliente puede
interactuar con cualquier servidor HTTP sin ninguna configuración especial. Esto no es del todo cierto para otras alternativas, como SOAP para los Servicios Web. •
Puesta en funcionamiento independiente. Este hecho es una realidad que debe
tratarse cuando se trabaja en Internet. Los clientes y servidores pueden ser puestas en funcionamiento durante años. Por tanto, los servidores antiguos deben ser capaces de entenderse con clientes actuales y viceversa. Diseñar un protocolo que permita este tipo de características resulta muy complicado. HTTP permite la extensibilidad mediante el uso de las cabeceras, a través de las URIs, a través de la habilidad para crear nuevos métodos y tipos de contenido. •
Compatibilidad con componentes intermedios. Los más populares intermediaros son
varios tipos de proxys para Web. Algunos de ellos, las caches, se utilizan para mejorar el rendimiento. Otros permiten reforzar las políticas de seguridad: firewalls. Y por último, otro tipo importante de intermediarios, gateway, permiten encapsular sistemas no propiamente Web. Por tanto, la compatibilidad con intermediarios nos permite reducir la latencia de interacción, reforzar la seguridad y encapsular otros sistemas.
32
Edwin Valencia Castillo