UNIVERSIDAD TECNICA PARTICULAR DE LOJA
La Universidad Católica de Loja
ESCUELA DE CIENCIAS DE LACOMPUTACIÓN
“ TECNOLOGÍAS DE WEB SEMÁNTICA ORIENTADA AL DESARROLLO DE SERVICIOS WEB”
PROFESIONAL EN FORMACIÓN Gloria Matilde Carrión Jiménez
DIRECTOR Ing. Samanta P. Cueva
CODIRECTOR Ing. Jorge López
LOJA – ECUADOR 2010
Tesis previa la obtención del
Título de Ingeniero en Sistemas
Informáticos y Computación
CERTIFICACIÓN
Ing. Samanta Patricia Cueva Carrión DIRECTORA DE TESIS
CERTIFICA:
Haber dirigido y supervisado el desarrollo del presente proyecto de tesis previo a la obtención del título de INGENIERA EN SISTEMAS INFORMÁTICOS Y COMPUTACIÓN, y una vez que este cumple con todas las exigencias y los requisitos legales establecidos por la Universidad Técnica Particular de Loja, autoriza su presentación para los fines legales pertinentes.
Loja, Marzo de 2010
………..……….
Ing. Samanta Patricia Cueva Carrión
AUTORÍA
El presente proyecto de tesis con cada una de sus observaciones, análisis, evaluaciones, conclusiones y recomendaciones emitidas, es de absoluta responsabilidad de la autora Gloria Matilde Carrión Jiménez.
Además, es necesario indicar que la información de otros autores empleada en el presente trabajo está debidamente especificada en fuentes de referencia y apartados bibliográficos.
...
Gloria Matilde Carrión Jiménez
CESIÓN DE DERECHOS
Yo, Gloria Matilde Carrión Jiménez, declaro conocer y aceptar la disposición del artículo 67 del Estatuto Orgánico de la Universidad Técnica Particular de Loja que en su parte pertinente textualmente dice: “Forman parte del Patrimonio de la Universidad, la propiedad intelectual de investigaciones, trabajos científicos o técnicos y tesis de Grado que se realicen a través, o con el apoyo financiero, académico o institucional (operativo) de la Universidad”.
……….
Gloria Matilde Carrión Jiménez
DEDICATORIA
Todos las personas tenemos aspiraciones en la vida y una de ellas para mi es terminar la carrera profesional, que ha sido plasmada con la culminación de la presente investigación que lo dedico de todo corazón en primer lugar a Dios que siempre ilumina mi vida y me da la sabiduría necesaria.
A mi papacito Amaro que desde el cielo me ilumina y guía mi camino y mi mamacita María por su valioso apoyo incondicional que me ha brindado en todo momento.
En especial a mi Esposo Sergio, por su comprensión, apoyo moral y permanente; a mis hijos Ronin y Cosme quienes han sido para mí una fuente de inspiración y estímulo para culminar con éxito mi carrera universitaria, quienes han sufrido por no dedicarles mi tiempo como se lo merecen.
Gloria Matilde
AGRADECIMIENTO
Dejo constancia de mis sinceros agradecimientos a la Universidad Técnica Particular de Loja, a nuestros catedráticos, quienes supieron brindar sus conocimientos con verdadero sentido de responsabilidad.
Agradezco al Ing. Nelson Piedra, Director de la Escuela de Ciencias de la Computación, quien nos brindó todo su valioso apoyo y asistencia durante el trayecto de carrera universitaria.
Mi agradecimiento especial a mi directora de tesis Ing. Samanta P. Cueva y al Codirector Ing.
Jorge López por su dedicación a este trabajo, sus conocimientos, sugerencias y por saber indicarme líneas y caminos a seguir, que han sido cruciales para el desarrollo satisfactorio de la presente investigación.
Finalmente a mi familia, por haber estado en todo momento animándome a continuar este camino y saber disculpar la falta de atención a ellos debido al tiempo ocupado en la investigación y desarrollo de este trabajo.
CONTENIDOS
CERTIFICACIONES I
CESIÓN DE DERECHOS II
AUTORÍA III
DEDICATORIA IV
AGRADECIMIENTO V
CONTENIDOS VI
ÍNDICE DE TABLAS X
ÍNDICE DE FIGURAS XI
CAPÍTULO I: ANÁLISIS DE LAS ARQUITECTURAS BASADAS EN SERVICIOS Y ARQUITECTURAS DE SERVICIOS WEB
1.1 Introducción 1
1.2 SOA: Arquitectura orientada a Servicios. 2 1.2.1 Principios de la orientación a Servicios 3
1.2.2 Elementos de SOA 4
1.2.3 Beneficios de una Arquitectura basada en Servicios 6
1.2.4 Arquitectura REST 7
1.2.4.1 Restricciones de REST 8
1.2.4.2 Elementos Arquitectónicos de REST 11
1.2.5 OASIS 13
1.3 Arquitectura de Servicios Web 15
1.3.1 Tecnologías Asociadas 15
1.3.1.1 Arquitectura SOAP 15
1.3.1.2 Estándar WSDL 19
1.3.1.3 Estándar UDDI 20
1.3.2 Características de REST y SOAP 24
1.3.3 Diferencias entre REST y SOAP 25
1.4 Esquemas de Intercambio de Mensajes 26
1.5 Orquestación Y Coreografía de Servicios 27
1.6 Agentes y Servicios Web 31
1.6.1 Agentes 31
1.6.2 Servicios Web 33
CAPÍTULO II: WEB SEMÁNTICA
2.1 Introducción 36
2.2 Arquitectura de la Web Semántica 37
2.3 Lenguaje de Marcado 40
2.3.1 XML 41
2.3.1.1 Definición 41
2.3.1.2 Usos 43
2.3.1.4 Espacios de nombres 44
2.3.1.5 XML Schema 46
2.3.1.6 Herramientas 50
2.4 Lenguaje de consulta 53
2.4.1 XQuery 54
2.4.2 RDF 57
2.4.2.1 Características de diseño de un RDF 58
2.4.2.2 Estructura de un RDF 59
2.4.2.3 Diferencias entre XML y RDF 61
2.4.3 RDF Schema 62
2.4.3.1 Características de RDFS 63
2.4.3.1 Limitaciones de RDFS 64
2.4.4 RDF: SPARQL 65
2.4.7 Herramientas existentes 66
2.5 Lógicas de Descripción 72
2.5.1 Fundamentos 72
2.6 Ontologías como herramienta para la descripción 73
2.6.1 Componentes de una Ontología 74
2.6.2 Clases de Ontologías 75
2.6.3 OWL: Web Ontology Language 76
2.6.4 Herramientas de Web Semántica 78
CAPÍTULO III: SERVICIOS WEB EN LA WEB SEMÁNTICA
3.1 Introducción 84
3.2 Arquitecturas de Servicios Web Semánticos 85
3.2.1 Conceptos y evolución histórica 85
3.3 Estándares de Servicios Web Semánticos 90
3.3.1 WSMO 90
3.3.1.1 Concepto y Estructura 90
3.3.1.2 Principios de Diseño 92
3.3.1.3 Elementos de WSMO 67
3.3.2 OWL-S 94
3.3.2. 1 Service Profile 96
3.3.2.2 Service Model 97
3.3.2.3 Service Grounding 98
3.3.3 WSDL-S 99
3.3.4 Otros Estándares 101
3.3.4.1 SAWSDL 101
3.3.4.2 SWSF 102
3.3.5 Comparación de Lenguajes
105
3.4 Servicios Web Semánticos para Sistemas Multiagente 107
CAPÍTULO IV: APLICACIONES DE WEB SEMÁNTICA PARA LOS SERVICIOS WEB DE LA UTPL
4.1 Introducción 108
4.2 Tendencias de desarrollo de Servicios Web Semánticos 109 4.3 Estrategia para crear Servicios Web Semántica para la UTPL 111
4.4 Aplicaciones para los Servicios Web de la UTPL 122
DISCUSIÓN
129CAPÍTULO V: CONCLUSIONES Y RECOMENDACIONES
5.1 Conclusiones Generales 134
5.2 Recomendaciones 137
REFERENCIAS BIBLIOGÁFICAS
138ÍNDICE DE TABLAS
Tabla 1. Ventajas y desventajas de SOAP y REST………..……….... 24
Tabla 2. Diferencias entre SOAP y REST……….…. 25
Tabla 3. Herramientas que trabajan con XML ……….….………..51
Tabla 4. Partes de una expresión RDF………..……….... 60
Tabla 5. Diferencias entre XML y RDF………..…..……. 61
Tabla 6. Estándares de Ontologías para Web Semántica……….….…… 79
Tabla 7. Comparación de herramientas de Ontologías………...….……83
Tabla 8. Comparación de Lenguajes de Servicios Web Semánticos………...……..106
Tabla 9. Estrategia de desarrollo de un SWS………..112
Tabla 10. Metodología para Crear una Ontología………..113
Tabla 11: Metodología de desarrollo de ontología a utilizar………..114
Tabla 12 Descripción de las capacidades e Interfaces de los Web Services de WSMO…..116
Tabla 13. Descripción de Modelo de Contexto de Ontología………..117
Tabla 14. Elemento de la Ontología de Contenido………..118
Tabla 15. Tipos de Mediadores de más utilizados en WSMO……….………. 120
ÍNDICE DE FIGURAS
Fig. 1. Funcionamiento básico de un SOA……….…..17
Fig. 2 Arquitectura de Web Semántica……….………..38
Fig 3. Grafo de una expresión RDF.………. 60
Fig.4. Ejemplo de RDF Shema……….. 63
Fig. 5. Arquitectura de Sésáme……….……… 67
Fig. 6. Evolución de la Web Tecnologías participantes en los SWS………..86
Fig. 7. Dimensiones de Servicios Web Semánticos………. 88
Fig. 8. Elementos de WSMO……….…………. 92
Fig.9. Ontologías de Alto nivel OWL-S……… 96
Fig. 10. Anotación Semántica de los elementos WSDL-S………99
Fig. 11. Modelo Ontología WSMO……….……….…117
Fig. 12. Arquitectura de la Propuesta……….124
Fig.13 Descripción del Servicio en WSMO………127
SERVICIOS Y ARQUITECTURAS DE SERVICIOS WEB
CAPÍTULO I
ANÁLISIS DE LAS ARQUITECTURAS BASADAS EN SERVICIOS Y ARQUITECTURAS DE SERVICIOS WEB
1.1 INTRODUCCIÓN
En los últimos tiempos gracias a la tecnología de Internet que ha tenido un avance significativo;
el ser humano cada vez quiere realizar una mayor cantidad de tareas con menos esfuerzo, las mismas que se trasladan desde su origen físico hasta el usuario final a través de internet; ésta tecnología se conoce como Servicios Web.
Según el W3C define a los Servicios Web como: “Un conjunto de aplicaciones o tecnologías con capacidad de interoperar en la Web a través del uso de estándares abiertos. Estas aplicaciones intercambian datos entre sí con el objetivo de ofrecer servicios; los mismos que son ofrecidos por proveedores remotos y los usuarios solicitan el servicio llamando a estos procedimientos a través de la Web”. [1]
En la primera fase se aborda lo relacionado a las arquitecturas orientadas a servicios y arquitectura de servicios Web dando a conocer algunas definiciones, descripción de los estándares que intervienen, características, diferencias entre arquitecturas para luego enfocar como intervienen el de intercambio de mensajes que se lleva a cabo en la orquestación y composición de los servicios Web.
Actualmente la mayoría de los Servicios Web utilizan la arquitectura de Servicios SOAP (Simple Object Access Protocol), pero existen otras arquitectura para servicios Web denominada REST (Representational State Transfer) y OASIS (Organization for the Advancement of Structured Information Standards). Las organizaciones OASIS y W3C son los comités responsables de la arquitectura y reglamentación de los Servicios Web.
El objetivo primordial de este capítulo se centra en analizar los protocolos y las tecnologías que constituyen los estándares de los Servicios Web, arquitecturas orientadas a servicios como SOA y REST así como las tecnologías asociadas a éstos como son: SOAP, WSDL, UDDI. Para luego analizar el esquema de intercambio de mensajes que se da en la composición y orquestación de Servicios y como intervienen los agentes en el descubrimiento de Servicios Web.
1.2 SOA: ARQUITECTURA ORIENTADA A SERVICIOS
Básicamente la Arquitectura Orientada a Servicios (Service Oriented Architecture), hace referencia a un concepto de arquitectura de software que especifica la utilización de servicios para dar soporte a los requerimientos del usuario, dicha arquitectura nos permite la creación de sistemas altamente escalables que satisfacen las necesidades de la organización y a su vez brinda una forma estándar de publicar e invocar los servicios para facilitar la interacción entre diferentes sistemas propios o de terceros independientemente de la plataforma utilizada.
SOA es una arquitectura que básicamente está orientada a un conjunto de servicios tanto de negocio como tecnológicos que interactuando entre sí nos proporcionan la lógica necesaria para construir aplicaciones de una manera rápida y cumpliendo con los principios de la Orientación a Servicios. Además SOA proporciona una serie de guías y recomendaciones para conseguir los objetivos que se impone una organización a la hora de desarrollar aplicaciones.
Por ello esta arquitectura surge de la necesidad de mejorar la integración e interoperabilidad entre aplicaciones; cuyo fin o propósito es la convergencia entre el desarrollo e integración que minimice las limitaciones entre aplicaciones. [2]
SOA es una plataforma basada en estándares que contiene funciones básicas como servicio de mensajería, Servicios Web, enrutamiento inteligente y transformación de datos para conectar y coordinar la interacción de aplicaciones de empresas. Dentro de la arquitectura de SOA la
funcionalidad se implementa en pequeños componentes autónomos reutilizables denominados Servicios.
1.2.1 PRINCIPIOS DE LA ORIENTACIÓN A SERVICIOS
Los Principios orientados a servicios según Thomas Erl [3] son:
“Los Servicios deben ser reusables”: Los servicios deben estar orientados a la reutilización de los mismos dentro de la aplicación o en un domino de aplicaciones incrementando de esta forma la productividad de la empresa.
“Los Servicios deben proporcionar un contrato formal”: Los servicios deben proporcionar un contrato en el que consten: el nombre del servicio, forma de acceso, funcionalidades, datos de entrada de cada una de las funcionalidades y los datos de salida. Por ello para acceder al servicio se lo realizará mediante el contrato logrando así la independencia y para los Servicios Web se concreta mediante la definición de interfaces con WSDL1
“Los Servicios deben tener bajo acoplamiento”: Los servicios tienen que ser independientes los unos de los otros. Este bajo acoplamiento hace que los servicios puedan ser reutilizables en su totalidad.
“Los Servicios deben permitir la composición”: Todo servicio debe ser construido pensando en ser utilizado para construir otros servicios genéricos de más alto nivel, el cual estará compuesto de servicios de más bajo nivel. En el caso de los Servicios Web, esto se logrará mediante el uso de los protocolos para orquestación (WS-BPEL)2 y coreografía (WS-CDL)3.
1 WSDL (Web Service Dscription Languaje).- Define una gramática para describir los Servicios de La red.
2 WS-BPEL(Business Process Execution Language) Es un estándar utilizado para componer múltiples servicios, sincrónicos y asincrónicos, dentro de flujos de proceso colaborativos y transaccionales.
3 WS-CDL(Web Services Choreography Description Language) Es un lenguaje basado en XML que describe colaboraciones punto a punto entre participantes.
“Los Servicios deben de ser autónomos”: Los Servicios debe tener su correspondiente entorno de ejecución; lo que permitirá ser reutilizable desde el punto de vista de la plataforma de ejecución.
“Los Servicios no deben tener estado”: Un servicio no debe guardar ningún tipo de información porque se pueden producir problemas de inconsistencia de datos. La solución, es que un servicio sólo contenga lógica, y que toda información esté almacenada en otro sistema de información de cualquier tipo.
“Los Servicios deben poder ser descubiertos”: Esta característica es muy relevante para que el servicio sea descubierto y pueda ser utilizado, evitando las creaciones repetidas de servicios con las mismas funcionalidades. En los Servicios Web, el descubrimiento se logrará publicando los interfaces de los servicios en registros UDDI4.
Cuando se desarrollan aplicaciones SOA es necesario tener en cuenta siempre estos principios, ya que nos guiarán para tomar ciertas decisiones de diseño complejas. Todos los principios guardan cierta relación y todos coinciden en la reusabilidad.
1.2.2 ELEMENTOS DE SOA
Existen diferentes elementos SOA los mismos que está agrupados en dos grupos: Unos que abarca los aspectos funcionales de la arquitectura y otros que abarcan aspectos de calidad de servicio: Los elementos funcionales comprenden: Transporte, Protocolo de comunicación, Descripción del Servicio, Servicio, Proceso de Negocio, Registro de Servicios. En lo que se refiere a la calidad de servicio comprende lo siguiente: Política, Seguridad, Transacciones, Administración. A continuación se detalla cada uno de ellos:
4 UDDI(Universal Description, Discovery and Integration) Es un estándar para registrar y descubrir Web Services.
Aspectos Funcionales de la Arquitectura
“Transporte”: Mecanismo utilizado para llevar las demandas de servicios desde un consumidor de servicio hasta un proveedor de servicio y las respectivas respuestas entre ellos.
“Protocolo de comunicación de servicio”: Mecanismo mediante el cual un proveedor de servicios y un consumidor de servicios notifica que está siendo solicitado y por ende recepta la respuesta.
“Descripción del servicio”: Es un esquema utilizado para describir qué servicio es, cómo se le puede invocar, y qué datos son necesarios para realizar su invocación.
“Servicio”: Es la implementación del servicio, que describe un servicio actual que está disponible a utilizar.
“Proceso de Negocio”: Es una colección de servicios invocados en secuencia, con un conjunto particular de reglas para satisfacer los requisitos de negocio.
“Registro de Servicios”: Consiste en un repositorio de descripciones de datos y servicios que pueden utilizar proveedores de servicios para publicar los mismos, así como consumidores de servicios para descubrir servicios disponibles.
Aspectos de la Calidad de Servicio
“Política”: Es la agrupación de todas las reglas por medio de las cuales el proveedor de servicio hace el mismo servicio disponible para los consumidores.
“Seguridad”: Son las reglas a utilizar para la identificación, autorización, control de acceso, integridad de los mensajes y la confidencialidad de los mismos.
“Transacciones”: Son todos los atributos que se pueden utilizar a un grupo de servicios para dar un resultado consistente y efectivo.
“Administración”: Administración o Gestión viene a ser el conjunto de atributos que pueden aplicarse para manejar los servicios ofrecidos.
1.2.3 BENEFICIOS DE UNA ARQUITECTURA ORIENTADA A SERVICIOS (SOA)
Una vez analizada la arquitectura SOA se concluye que ofrece variedad de beneficios los mismos que están relacionados a integrar aplicaciones a través del uso adecuado de tecnologías cuyas bondades se resume en los siguientes aspectos:
Reusabilidad: Es un factor importante para la integración de aplicaciones y sistemas nuevos o los existentes para compartir información y datos entre aplicaciones incrementándose así la calidad del servicio y la productividad de la empresa.
Interoperabilidad: Hace referencia a la independencia de plataforma de ejecución a la hora de establecer la comunicación entre el cliente y el servicio para poder entenderse mutuamente.
Escabilidad: Las aplicaciones con arquitectura SOA tienden a escalar fácilmente, debido a que existe menos dependencia entre la aplicación que solicita y el servicio que ésta utiliza;
esto se debe a que los servicios SOA son débilmente acoplados.
Flexibilidad: Los servicios SOA al ser débilmente acoplados son más flexibles que las aplicaciones fuertemente acoplados por ende el desarrollo de las aplicaciones son más productivas, flexibles, seguras y manejables para gestionar procesos a medida que evolucionan las necesidades de la organización.
Costo: Reduce costos y tiempo en el desarrollo de aplicaciones por la reutilización de módulos de aplicaciones y por ende se reduce implícitamente el costo de mantenimiento.
Lo más importante de la arquitectura orientada a servicios es que cada elemento de un SOA puede ser trasladado, intercambiado y modificado; debido a que los servicios existen de una
forma desacoplada, los mismos pueden ser combinados de diferentes formas según las circunstancias. La posibilidad de crear procesos y componer aplicaciones a partir de estos servicios junto con la reutilización y la interoperabilidad basada en estándares permite a las aplicaciones ser flexibles al cambio a medida que evolucionan los requerimientos de la empresa. [4]
1.2.4 ARQUITECTURA REST
REST (Representational State Transfer) es una arquitectura de aplicaciones Web propuesta por Roy Fielding en su tesis doctoral (2000) “Architectural Styles and the Design of Network-based Software Architectures”5, que consiste en un conjunto coordinado de restricciones que controlan el funcionamiento y las características de los elementos de la arquitectura que permiten las relaciones de unos elementos con otros.
Ésta arquitectura está diseñada para ofrecer un buen desempeño, escalabilidad y abstracción de recursos, donde cada petición HTTP contiene suficiente información para dar respuesta a la petición del usuario, sin necesidad que el cliente o el servidor tenga que recordar cada vez el estado de su comunicación que se encuentra. Además ofrece escabilidad en la interacción con sus componentes; de manera que el cliente puede actuar con cualquier servidor HTTP gracias a la generalidad de interface que posee esta tecnología, que es independiente y compatible con componentes intermedios.
Cuando se va a realizar una implementación de un Servicio Web REST se debe considerar cuatro principios fundamentales, los mismos que se detallan a continuación: [5]
“Utiliza los métodos HTTP de manera explícita”: Este principio se usa para ver la consistencia en la definición del protocolo. Además establecer una asociación uno-a-uno
5 http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
entre las operaciones de crear, leer, actualizar y borrar los métodos HTTP. De acuerdo a esta asociación: POST (crea un recurso en el servidor), GET (Obtiene un recurso), PUT (actualiza o cambia el estado de un recurso), DELETE (elimina un recurso).
“No mantiene estado”: Un servicio sin estado no sólo funciona mejor, sino que además mueve la responsabilidad de mantener el estado al cliente de la aplicación; el servidor es responsable de generar las respuestas y proveer una interfaz que le permita al cliente mantener el estado de la aplicación por su propia cuenta.
“Expone URIs con forma de directorios” : Las URIs son jerárquicas, a través de un único directorio raíz se puede ir accediendo a través de los subdirectorios para exponer las áreas principales del servicio. Una URI no es solamente una cadena de caracteres delimitada por barras, sino más bien un árbol con subordinados y padres organizados como nodos.
“Transfiere XML, JavaScript Object Notation (JSON6), o ambos”: tiene que ver con el formato de los datos que la aplicación y el servicio intercambian en las peticiones/respuestas. Es decir que vale la pena mantener las cosas simples, legibles por humanos y conectadas. Este servicio es utilizado por distintos clientes escritos en diferentes lenguajes, corriendo en diversas plataformas y dispositivos.
1.2.4.1 RESTRICCIONES DE REST
Las restricciones son condiciones que deben cumplirse para que una Arquitectura de Servicios Web pueda ser considerada tipo REST. Esta arquitectura contiene seis clases de restricciones según TOMAS, Fielding Roy: [6]
1. Cliente Servidor
6 http://es.wikipedia.org/wiki/JSON
2. Sin estado 3. Caché
4. Sistema de capas 5. Interfaz Uniforme 6. Código bajo demanda
1. “Cliente Servidor”: Consiste en separar la parte del cliente y del servidor al inicio para distinguir la interfaz del usuario del almacenamiento de datos, lo que permite a los componentes desarrollarse independientemente. De esta manera se mejora la portabilidad de la interfaz de usuario y también se mejora la escalabilidad porque se simplifica los componentes del servidor al no tener que implementar las funcionalidades que van asociadas a la interfaz del usuario.
2. “Sin Estado (Stateless)”: Consiste en que cada petición del cliente debe contener toda la formación necesaria para que el servidor la comprenda y no necesite mirar ningún dato almacenado previamente sobre el contexto de la comunicación. El estado de la sesión se guarda íntegramente en el cliente. Ésta restricción mejora la “visibilidad”, “eficiencia” y
“escabilidad” por las siguientes razones:
La visibilidad mejora en el sentido que el servidor no tiene que ocuparse de mirar en otros sitios, ni realizar otras operaciones para entender la naturaleza de una petición simple.
La eficiencia mejora ya que es más fácil recuperarse de errores parciales.
La escabilidad incrementa porque los componentes pueden liberar más rápidamente lo recursos, ya que no tienen almacenados los estados entre las peticiones.
3. “Caché”: Esta restricción hace referencia a las respuestas de una petición que tiene que ser etiquetadas como cacheable o no-cacheable. Si una respuesta es cacheable, al cliente caché se
le concede permiso para reutilizar la respuesta posteriormente si éste realiza una petición equivalente. La ventaja de esta restricción es que mejora la eficiencia y escabilidad al evitar algunas peticiones al servidor y se reducirá el tiempo medio de espera de un conjunto de interacciones. La desventaja es que los datos obtenidos de caché difieran de los obtenidos realizando la petición directamente al servidor.
4. “Sistema de Capas”: Permite tener una arquitectura compuesta por capas jerárquicas, limitando el comportamiento de los componentes porque no pueden ver más allá de la capa con la que está interactuando. Además se pueden simplificar los componentes trasladando funcionalidades de uso poco frecuentes hacia sistemas intermedios compartidos.
La desventaja es que se añaden cabeceras y retrasos al procesamiento de datos; pero se puede reducir este riesgo por los beneficios de usar un caché compartido en los sistemas intermedios.
5. “Interfaz Uniforme”: Se usa una interfaz uniforme entre los componentes para simplificar la arquitectura del sistema global y la visibilidad de interacciones se mejora considerablemente.
Las implementaciones se separan de los servicios que ofrecen para lograr la independencia.
Como desventaja se puede considerar la disminución de la eficiencia porque la información transferida está en una forma estandarizada y no según las necesidades que tenga la aplicación.
El interfaz de REST está creado para ser eficiente con transferencias de datos hipermedios.
Para obtener una interfaz uniforme, REST7 define cuatro restricciones de interfaz:
Identificación de recursos.
Manipulación de recursos a través de sus representaciones.
Mensajes auto-descriptivos.
Hipermedios como el motor del estado de la aplicación.
7 http://forge.morfeo-
project.org/wiki/index.php/D.3.2_Documento_de_definici%C3%B3n_de_modelos_avanzados_de_comunicaci%C3
%B3n_y_composici%C3%B3n_de_recursos#Interfaz_Uniforme
6. “Código bajo demanda”: Esta restricción es opcional, consiste en permitir a los clientes tener la funcionalidad de descargar y ejecutar código en forma de applets y scripts. Esto simplifica el lado del cliente porque reduce el número de funcionalidades que tiene que tener implementadas al crearse. Las funcionalidades se pueden descargar posteriormente aumentando así la extensibilidad del sistema. La principal desventaja de esta restricción es que reduce la visibilidad y puede influir en la seguridad del sistema.
1.2.4.2 ELEMENTOS ARQUITECTONICOS DE REST
Siguiendo la línea de la Arquitectura REST hasta ahora hemos descrito las restricciones que utiliza para controlar el funcionamiento y las relaciones entre los elementos que son tres:
componentes, conectores y datos. Ahora se analizará como Roy T. Fielding concibió cada uno de estos elementos para acoplarse dentro de REST.
Componente: Es una unidad abstracta de instrucciones software y estados internos que proporciona una transformación de los datos a través de su interfaz, éstos se comunican trasfiriendo representaciones de un recurso en un formato que se ajusta a un conjunto de tipos de datos estándares. Los tipos de datos son seleccionados dinámicamente en base a las capacidades o requerimientos del receptor y en la naturaleza del recurso. Los componentes principales de REST son Agente Usuario, Servidor, Gateway (puerta de acceso) y Proxy.
Conector: Mecanismo abstracto que se encarga de la comunicación, coordinación y cooperación entre componentes. Los conectores principales de REST son Cliente, Servidor y Caché. Pero existen otros que están en segundo plano y éstos son: Resolver y Túnel.
Dato: “Es un elemento de información que se transfiere desde o hacia un componente a través de un conector”. Por ejemplo cuando seleccionamos un link, la información debe
trasladarse desde la localización donde se encuentra hasta donde será utilizado. En cambio en los procesos distribuidos se mueve el “proceso agente” hasta los datos, en REST se mueven los datos hasta el proceso.
Usos de la Arquitectura REST
Una vez analizada brevemente la arquitectura REST es necesario enfocar los usos frecuentes que se le da a esta arquitectura considerando la gama de características que ofrece y el fin para el que deseamos implementar. En primer lugar tenemos que Amazon es pionera en el uso de REST, se beneficia de una base de datos con todos los productos que vende, a éstos se acceden como recursos y no como métodos de búsqueda.
Esta arquitectura se considera apropiada utilizarla en los siguientes casos:
Cuando necesitemos una representación distinta a XML.
Cuando los servicios Web no requieran guardar el estado de su interacción.
Cuando el servicio productor y el servicio consumidor se entienden mutuamente, que conocen el contexto y el contenido que va a ser comunicado.
Cuando se pasa tanto contenido como contexto, debido a que no hay una manera formal de describir las interfaces de servicios Web se ponen de acuerdo las dos partes en lo que se refiere a esquemas para intercambiar datos y la forma de procesarlos para que sean comprensibles.
REST es particularmente útil para dispositivos con escasos recursos como PDAs o teléfonos móviles, para los que las extensas cabeceras y capas adicionales de elementos SOAP son excesivas.
Los servicios Web REST permite un desarrollo ágil, disminuyen la utilización de recursos (CPU, memoria, ancho de banda, tiempo de desarrollo) al interior de la organización.
1.2.5 OASIS
OASIS8(1993) (Organization for the Advancement of Structured Information Standards) es un consorcio internacional sin ánimo de lucro, que gestiona el desarrollo, la convergencia y la adopción de los estándares sobre comercio electrónico y sus propios miembros establecen la agenda técnica de OASIS, utilizando un proceso abierto y ligero, diseñado explícitamente para fomentar el consenso de la industria y unificar esfuerzos. El consorcio crea estándares abiertos en los ámbitos de Servicios Web, Seguridad, Comercio-Electrónico y estandarización en el sector público, así como para mercados de aplicaciones específicas.
Dentro del área de Servicios Web OASIS ha impulsado la interpretación del marco XML y su traducción a normas útiles para el negocio electrónico con el nombre de ebXML9 (1999), El proyecto original contempla y proporciona la especificación de cinco capas de datos sustantivos, que comprendían normas XML para:
Procesos comerciales
Componentes de datos fundamentales
Acuerdos de protocolos de colaboración
Mensajería
Registros y almacenes
Objetivo de OASIS
OASIS propone una solución innovadora, que facilita la interoperabilidad, conectividad transparente al usuario y la distribución de contenidos entre diferentes servicios y ontologías en todos los ámbitos de relevancia para los usuarios que se apunten a utilizar esta tecnología.
OASIS define la Orientación a Servicios como:
8 http://www.w3c.es/Prensa/2007/nota070130_Webcgm.html
9 ebXML (comercio electrónico utilizando eXtensible Markup Language).
“Un paradigma para la organización y uso de funcionalidades que se encuentran distribuidas en distintos servicios, proporcionando un modo uniforme de ofrecer, descubrir e interactuar con ellos” [7]
El objetivo de OASIS básicamente está orientado a crear una arquitectura de referencia y abierta, que está basada en ontologías y servicios semánticos, que permiten una interconexión simple y rentable de servicios nuevos o ya existentes, en todas las áreas. Tanto la arquitectura abierta de referencia como las herramientas relacionadas están disponibles en Open Source.
Estándares aprobados
OASIS ha aprobado diferentes estándares entre los cuales tenemos: [8]
UDDI 2.0 (Universal Description, Discovery and Integration), Lenguaje para la descripción de los Servicios Web y es uno de los estándares primordiales en la arquitectura de Servicios Web junto a XML, SOAP (Simple Object Access Protocol) y WSDL (Web Services Description Language)
BPEL 2.0, Lenguaje diseñado para la composición de Servicios Web
Open Document (OASIS Open Document Format for Office Applications): Contiene un formato abierto de documentos para guardar documentos relacionados con ofimática como: hojas de cálculo, memorándums, gráficos y presentaciones.
DocBook (DocBook), lenguaje de marcado para documentación técnica. Fue diseñado para elaborar documentación técnica que está relacionada con hardware y software pero puede ser usado para cualquier documentación de diferente tipo.
1.3 ARQUITECTURA DE SERVICIOS WEB
La arquitectura de Servicios Web está enfocada al uso exclusivo de los Web Services, los cuales comunican aplicaciones permitiendo compartir información, invocan funciones independientemente de cómo se hayan creado éstas. La comunicación se caracteriza por el intercambio de mensajes XML y por ser independiente del protocolo de comunicación.
Estos Servicios Web son aplicaciones que utilizan estándares para el transporte, codificación y protocolo de intercambio de información, que permite la intercomunicación entre sistemas o aplicaciones de cualquier plataforma. En consecuencia un Servicio Web hace referencia a un conjunto de tecnologías y estándares de software para el intercambio de datos entre aplicaciones. Estos estándares son: SOAP, WDSL y UDDI que en las secciones posteriores se analizarán con detenimiento cada uno de ellos.
1.3.1 TECNOLOGÍAS ASOCIADAS
1.3.1.1 SOAP
SOAP (Simple Object Access Protocol), en Junio del 2003 alcanzó la fase de recomendación oficial de W3C. SOAP es un protocolo que proporciona un mecanismo para empaquetar mensajes y permite el intercambio de información en un entorno descentralizado y distribuido. Además simplifica el acceso a los objetos, permitiendo a las aplicaciones invocar métodos objetos o funciones, que residen en sistemas remotos. Se basa en XML y describe un formato de mensajería para la comunicación entre equipos. [9]
SOAP utiliza tecnologías relacionadas con XML para definir un marco de trabajo extensible para los mensajes y provee una estructura de mensajes capaz de ser intercambiada sobre
una gran cantidad de protocolos de soporte. El marco de trabajo está diseñado para ser independiente de cualquier modelo de programación o cualquier semántica específica de alguna implementación. SOAP consta de tres partes fundamentales:
“El SOAP envelope”: Se encarga de definir el marco de trabajo que determina qué se puede introducir en un mensaje, quién lo debe realizar y si es opcional u obligatoria esta operación.
“Las reglas de codificación SOAP”: Define la forma de serialización que utilizará para encapsular en los mensajes los diferentes tipos de datos.
“La representación SOAP RPC”: Define un modo de funcionamiento a la hora de realizar llamadas a procedimientos remotos y la obtención de sus resultados.
El estándar SOAP generalmente es utilizado en un amplio rango de servidores de aplicaciones que trabajan mediante el modelo de comunicación RPC (Remote Procedure Call). Pero los Servicios Web basados en SOAP son más utilizados por parte de desarrolladores de software y analistas al contrario de los Servicios Web basados en RPC. La especificación SOAP menciona que las aplicaciones deben ser independientes del lenguaje de desarrollo, por lo que las aplicaciones cliente y servidor pueden estar escritas en cualquier lenguaje disponible.
Procesamiento de SOAP
En este apartado se aborda como SOAP procesa un mensaje y quien interviene en esta tarea.
Primeramente se tiene que SOAP provee un modelo de procesamiento distribuido en el que un mensaje es originado por un emisor inicial SOAP, y enviado a un receptor final SOAP a través de más intermediarios o directamente. Este modelo puede soportar muchos Patrones de Intercambio de Mensajes, incluyendo mensajes unidireccionales, interacciones del tipo petición/respuesta y conversaciones punto a punto.
Este modelo especifica cómo un receptor SOAP procesa el mensaje que le ha llegado; pero no está contemplado el mantener ningún estado en la comunicación, o el llevar un control de la correlación de los mensajes. Sería responsabilidad de las características adicionales el definir de alguna forma este tipo de procesamiento.
Las tecnologías básicas de los Servicios Web; utilizan SOAP como lenguaje de intercambio de mensajes, WSDL como lenguaje para la descripción de los servicios y UDDI para la publicación de los servicios Web. A continuación en la figura 1 se muestra la estructura básica de funcionamiento de SOA.
Fig. 1. Funcionamiento básico de un SOA [tomado de [10]]
Básicamente se identifica tres roles que son: “Consumidor de Servicio, Proveedor de Servicio y registro de Servicios”. La interacción de cada uno de ellos es como se detalla a continuación:
1. El proveedor del servicio almacena en el registro UDDI el documento de descripción de este y es el encargado de implementar el servicio Web para ofrecerlo a los consumidores o clientes.
2. El consumidor del servicio busca en el registro un servicio Web que pueda adaptarse a sus necesidades. Es decir solicita el servicio y por ende lo consume.
3. Una vez seleccionado el servicio, el cliente lo invoca mediante el envío de un mensaje SOAP, en el cual se indica la acción a realizar y los datos de entrada que contiene.
4. El servicio Web recibe la petición y ejecuta la funcionalidad, luego para finalizar envía un mensaje SOAP el proveedor al solicitante con los resultados obtenidos.
Cuando utilizar SOAP
Una vez analizada la tecnología de SOAP dentro de lo estándares de la Arquitectura Orientada a Servicios Web es necesario dar un aporte a cerca de la factibilidad de uso de esta tecnología para aprovechar todas las bondades que esta nos ofrece; por eso se sugiere utilizar en en los siguientes casos:
Cuando se establece un contrato formal para la descripción de la interfaz que el servicio ofrece, porque al trabajar con lenguaje de Descripción de Servicios Web (WSDL), permite describir con detalles el servicio Web.
Cuando la arquitectura necesita manejar procesado asíncrono e invocación. En estos casos, la infraestructura proporcionada por estándares como WSRM10 y APIs como JAX-WS11 junto con la asincronía por el lado del cliente nos permitirán el soporte de estas características.
Cuando el servidor necesite mantener el estado de la conversación.
Cuando múltiples instancias del proceso comparten la misma operación.
Cuando el flujo de eventos necesiten ser orquestados y utilizar muchas operaciones con pocos recursos y el diseño de las aplicaciones requieran ser distribuidas.
Cuando la arquitectura debe abordar requerimientos complejos como transacciones, seguridad direccionamiento.
Cuando la aplicación no necesite estar fuertemente acoplado a ningún protocolo de transporte.
Cuando se requiera utilizar cualquier lenguaje de programación.
Cuando se requiera interoperabilidad entre múltiples entornos
10 WSRM(Windows System Resource Manager) http://technet.microsoft.com/en- us/windowsserver/bb405952.aspx
11 https://jax-ws.dev.java.net/
1.3.1.2 WSDL
WSDL (Web Service Definition Languaje), es publicado por el W3C en Marzo 2001, éste estándar describe la interfaz pública de los Servicios Web. Está basado en XML y describe la forma de comunicación, es decir, los requisitos del protocolo y los formatos de los mensajes necesarios para interactuar con los Servicios. WSDL establece un contrato entre el proveedor de servicio y el consumidor del Servicio, mediante el cual el proveedor de servicios indica los siguientes puntos dentro del contrato:
“Las funciones que pueden invocar”.
“Los tipos de datos que utilizan esas funcione”.
“El protocolo de transporte que utilizará para el enviar y recibir los mensajes”.
“Como acceder a los servicios, es decir, mediante que URL se utilizan los servicios”. [11].
Básicamente en un documento WSDL se definen los detalles del servicio como: operaciones, tipos de datos y protocolo utilizado; y al momento de la definición de documento WSDL, se genera automáticamente el componente cliente para su invocación remota.
WSDL define una gramática XML orientada a describir en forma estructurada, la funcionalidad de un Servicio Web y la forma en que esa funcionalidad se hace disponible. Además describe los servicios de red como colecciones de puntos finales de comunicación capaces de intercambiar mensajes describiendo las comunicaciones en forma estructurada.
Estructura del documento WSDL
WSDL permite describir en forma abstracta operaciones y mensajes, prescindiendo de las especificaciones de protocolo y tipos de datos, además vincula las descripciones abstractas a
una implementación concreta de protocolos y tipos de datos, permitiendo la reutilización de las definiciones abstractas.
Una descripción WSDL diferencia dos partes fundamentales al crear un documento, éstas son:
“Parte concreta y parte abstracta” la primera define el "como" y "donde"; y la segunda define qué hace el servicio a través de los mensajes que envía y recibe. Por esta razón, un documento WSDL según el W3C utiliza seis elementos en la definición de servicios de red: Types, messages, portType, Binding, Port, Service ; los mismos que se describe a continuación: [12].
“Tipos” (Types): Especifican las definiciones de tipos de datos utilizados para describir los mensajes intercambiados.
“Mensaje”(messages): Representa una definición abstracta de los datos que están siendo transmitidos. El mensaje de divide en una serie de partes lógicas, cada una de las cuales se asocia con alguna definición de algún sistema de tipos.
“Tipo de Puerto”(portType): Se utiliza para definir un conjunto de operaciones abstractas. Cada operación hace referencia a un mensaje de entrada y uno de salida.
“Vinculación”(Binding): Especifica un protocolo concreto y el formato de los datos de las operaciones para un tipo de puerto determinado.
“Puerto” (Port): Especifica un punto final único que se define como la combinación de un enlace y una dirección de red, para así definir un único nodo de comunicación.
“Servicio” (Service): Es el conjunto de puntos finales relacionados que se utiliza para unir un conjunto de puertos relacionados.
1.3.1.3 UDDI
Dentro de la Arquitectura de Servicios Web se tiene UDDI12 (Universal Description, Discovery and Integration), que es uno de los protocolos fundamentales que proporciona una
12 http://triana.escet.urjc.es/apliweb/SOAP-WSDL-UDDI.pdf
plataforma estándar e interoperable que permite a las organizaciones y a la aplicaciones encontrar y usar de forma rápida, fácil y dinámica los Servicios Web a través de Internet.
La versión actual de UDDI es la 3.0 (Agosto, 2003), siendo gestionada por Organization for the Advancement of Structured Information Standards (OASIS). “La implementación de estas especificaciones se denomina “Registro UDDI”, el cual proporciona un conjunto de Servicios Web de registro y consulta vía SOAP. El propósito de un registro UDDI es la representación de datos y metadatos acerca de Servicios Web. Tanto para ser usado en una red pública como dentro de la infraestructura interna de una organización, un registro UDDI ofrece un mecanismo basado en estándares para clasificar, catalogar y manejar servicios web de forma de que puedan ser descubiertos y consumidos por otras aplicaciones.
UDDI es el estándar básico para la publicación y el descubrimiento de información sobre los Servicios Web, cuyo propósito es ser accedido por los mensajes SOAP y dar paso a los documentos WSDL, en donde se describe el protocolo y el formato de mensaje para interactuar con Servicios Web.
El método utilizado por UDDI para el descubrimiento de Servicios Web consiste en tener un registro de aquellos servicios que se encuentran distribuidos a través de la Web y en éste registro distribuido, los negocios y los servicios se describen utilizando un formato XML, para que los datos estructurados en esos documentos XML sean de fácil búsqueda, análisis y manipulación.
El modo de operar de este estándar se describe a continuación: los proveedores de los Servicios Web los publican en el registro UDDI una vez publicados se mantienen allí apuntadores a la descripción del Servicio Web. UDDI permite a los clientes buscar dicho registro, encontrar el servicio deseado y extraer sus detalles.
El estándar UDDI contiene dos partes fundamentales dentro de una organización las mismas que son: Reutilización de código y configuración dinámica de aplicaciones. El directorio o registro es definido como una jerarquía de entidades “business”, “service” y “binding” cuyas descripciones son expresadas en XML. Entre las características de ésta tecnología se describe las siguientes: [13]
“Soporte para firma digital”
“Separación de los datos de una entidad UDDI de los metadatos asociados”.
“Usos de esquemas de XML”.
“Soporte de Lenguaje”.
UDDI es un elemento central del grupo de estándares involucrados en la tecnología Servicios Web. Es el mediador a través del cual se conocen los posibles clientes con los proveedores de los servicios. Define un método estándar para publicar y descubrir servicios en el contexto SOA (Alvez, et al., 2006).
Los UDDI se clasifican en: Páginas blancas (información de contactos, listados de organizaciones y servicios), páginas amarillas (información de industria, clasificación de compañías y servicios Web de acuerdo a una taxonomía) y páginas verdes (información técnica y especificaciones).
Estructura de Datos con UDDI
Dentro de la arquitectura de Servicios Web, la estructura de datos de UDDI definida por OASIS contiene cuatro tipos de información: BusinessEntity, BusinessService, BindingTemplate, tModel . [14]
“BusinessEntity”: Describe al proveedor del servicio Web; es decir, contiene datos como nombre de la empresa, detalle de contacto, descripción en lenguaje natural de las actividades de la empresa y otra información de contacto.
“BusinessService”: Describe un grupo de Servicios Web relacionados ofrecidos por una empresa en diferentes direcciones versiones y tecnologías. Una businessEntity se compone de uno o varios Servicios BusinessService, y un elemento BusinessService puede ser usado por varios elementos BusinessService y también puede contener elementos de clasificación.
“BindingTemplate”: Describe un único Servicio Web, describe la información técnica para utilizar el servicio, la misma que puede ser: dirección del servicio, referencias de documentos describiendo la interfaz u otras propiedades. Cada elemento BusinessService puede tener uno o varios elementos BindingTemplate.
“tModel”: Representa especificaciones técnicas, metadatos sobre las especificaciones del documento, el nombre puntero URL, es presentado en forma de un documento WSDL. También pueden aparecer las categorías en las que se puede elaborar el servicio.
1.3.2 CARACTERISTICAS DE REST Y SOAP
Una vez revisadas las arquitecturas de REST y SOAP se puede concluir en algunas ventajas y desventajas de cada una de ellas, las mismas que se describen a continuación [tabla 1].
VENTAJAS DESVENTAJAS
SOAP -Aprovecha los estándares existentes en la industria (XML, HTTP, SMPT)
-Permite interoperabilidad entre múltiples entornos
-Los datos como las funciones se describen en XML, lo que hace del protocolo fácil de utilizar y muy sólido.
-No se encuentra fuertemente asociado con ningún protocolo de transporte.
-Facilidad para utilizar cualquier lenguaje.
- Un cambio en el contrato de un servicio, afecta a todas las implementaciones de los clientes, técnicamente tendrán que regenerar los proxys para cada servicio.
- No dispone de un sistema de dirección global.
-No hace uso de mecanismos de caché.
- No dispone de puertos dedicados para diferentes tipos de modificaciones.
-Las instancias del proceso son creadas implícitamente.
- Problemas de interoperabilidad.
REST -Soporte universal y simple desde cualquier lenguaje o plataforma.
- Funciona con XML pero también con otros formatos (XHTM, JSON).
-Mejores tiempos de respuesta y disminución de carga en servidor, gracias al mecanismo caché y los mensajes auto-descriptivos
- Facilita desarrollo de clientes al tener menor dependencia del servidor.
- Mayor escalabilidad al no requerir mantenimiento de estado
- Mayor estabilidad frente a futuros cambios.
- No existen actualmente variedad de herramientas de desarrollo.
- Maneja gran número de objetos.
-El espacio de nombres (URIs) puede ser con el tiempo y cantidad de información un poco engorroso.
-La dirección sintáctica/semántica muy informal (orientadas al usuario).
Tabla1. Ventajas y Desventajas de SOAP y REST13
13 http://searchwebservices.techtarget.com/tip/0,289483,sid26_gci1227190,00.html
1.3.3 DIFERENCIAS ENTRE REST Y SOAP
Al analizar SOAP y REST se encontraron algunas diferencias enfocadas desde varios puntos de vista, las cuales se describen en la siguiente tabla [Tabla 2]
CARACTERISTICAS SOAP REST
Soporte de
documentos.
Solo soporta XML como documentos de intercambio, basados en el protocolo SOAP
Brinda recursos y variedad de representaciones como: XML, HTML, text, pdf, binario
Definición de Operaciones
Las operaciones se definen en los mensajes.
Las operaciones se definen en WSDL
Definición de protocolo.
Elige un protocolo de transporte apropiado y define las políticas de calidad de Servicio y de Seguridad
Depende directamente del protocolo HTPP, este expone siempre la misma interface a
todos los consumidores,
mediante operaciones bien
definidas: POST, GET, PUT y DELETE
Utilización de Recursos.
Realiza varias operaciones con escasos recursos.
Realiza pocas operaciones con muchos recursos.
Tipos de
Componentes.
Componentes fuertemente acoplados.
Componentes débilmente acoplados
Intercambio de Mensajes.
Síncrono y Asíncrono. Síncrono Mantenimiento de
Estado.
Los mensajes contienen sólo datos y el servidor mantiene el estado de la conversación.
Los recursos contienen datos y enlaces y el servidor no mantiene estado de la conversación, el cliente mantiene el estado y no se permite sesiones.
Definición de Operaciones.
Describe las operaciones del servicio en el documento WSDL
Las operaciones se definen en los mensajes
Tabla 2. Diferencias entre SOAP y REST
1.4 ESQUEMA DE INTERCAMBIO DE MENSAJES
En este apartado se aborda lo relacionado al intercambio de mensajes que gracias a SOAP y el protocolo HTTP que son la base tecnológica de la mensajería y del transporte respectivamente, se lleva a cabo sin inconveniente para prestar un buen servicio al usuario. Es por ello que los Servicios Web14 se definen a menudo como “síncrono o sin estado”.
Síncrono: Cuando un consumidor realiza una invocación se envía un mensaje de petición y a continuación espera una respuesta, lo que se traduce en que el proveedor debe enviar un mensaje de respuesta.
Sin estado: Es porque no existe relación alguna entre dos invocaciones consecutivas del mismo consumidor al mismo proveedor; es decir, cada vez que se realiza una invocación en la parte servidor, se instancia un componente servidor quien recibirá la petición, la procesa y devuelve un mensaje de respuesta y allí acaba la invocación; la próxima invocación que se realice no tendrá relación alguna con la anterior porque se ejecuta en una instancia nueva del servicio proveedor.
El “sincronismo” y la “ausencia de estados” añaden un conjunto de limitaciones que no permiten aplicar la tecnología en situaciones que desearíamos por ejemplo transacciones de larga duración en el que el tiempo de ejecución excede lo razonable para una aplicación online.
Para implementar transacciones de larga duración dentro de la arquitectura de Servicios Web se requiere utilizar un esquema “asíncrono” de intercambio de mensajes, donde el cliente no espere por la respuesta de un proveedor, sino que sea éste que al final del proceso informe al
14 http://grids.ucs.indiana.edu/ptliupages/publications/Geoinformatics05_asayar.pdf
cliente dicho evento. El esquema de asíncrono debe tomar en cuenta algunas tareas entre las cuales tenemos: [15]
Los mensajes deben ser unívocamente identificados, ya que las peticiones y respuestas van a ser entregadas sin orden a los mismos proveedores y clientes. Por este motivo se necesita una manera de identificar todos los mensajes que formen parte de un mismo diálogo, a los que se conoce como conjunto de invocaciones.
Los mensajes de respuesta pueden ser entregados a los clientes en cualquier momento.
Actualmente existen dos modelos que permiten la entrega asíncrona de mensajes que son polling y callback
Polling15(Sondeo): Los clientes hacen la invocación del servicio y como respuesta a la invocación recibe un ticket o identificador, lo que le permite al cliente tener una respuesta en lo posterior. Luego el cliente tiene que estar continuamente interrogando al servicio Web a la espera que se produzca una respuesta.
Callback16(retrollamada): El cliente realiza una invocación que finaliza con una respuesta que indica la aceptación de dicha invocación, así como la recepción exitosa del mensaje correspondiente. Existen cuatro categorías de invocación asíncrona en relación al intercambio de mensajes que generen.
Solo Envío: El cliente envía un mensaje y no espera respuesta (arranque de un proceso)
Envío y recepción: El cliente envía un mensaje y espera respuesta.
Recepción y envío: Se recibe un mensaje y se envía una respuesta (punto de vista de un proveedor de servicios).
Solo recepción: Se recibe un mensaje y no se envía respuesta(mensajes desatendidos)
15 http://es.wikipedia.org/wiki/Polling
16 http://es.wikipedia.org/wiki/Callback_(programaci%C3%B3n)
La construcción de servicios Web asíncronos depende en gran medida de la plataforma y de los protocolos sobre los que se han desarrollado. Las aplicaciones cliente deberán estar preparadas para invocar un servicio Web de forma asíncrona.
1.5 ORQUESTACIÓN Y COREOGRAFÍA DE SERVICIOS
ORQUESTACIÓN DE SERVICIOS
En la Arquitectura de Servicios Web una área importante que se debe considerar es la Orquestación de Servicios; que se da al momento que un solo servicio no satisface las necesidades del usuario por eso surge la composición de servicios para ofrecer mejores resultados.
En un análisis de “Orquestación Vs. Coreografía de Servicios” que hace Márquez Santiago define a la orquestación como: “Un proceso Web es de orquestación de servicios cuando es controlado totalmente por una única entidad. Ésta define completamente las interacciones con los servicios componentes, y la lógica requerida para conducir correctamente esas interacciones. La orquestación, siempre representamos el control del proceso del servicio desde el punto de vista de una de las partes participantes que intervienen en el mismo”. [16]
El proceso de orquestación de servicios describe el comportamiento que el servicio principal implementa para realizar un flujo de proceso, y la forma en que un proceso ejecutable interacciona con servicios internos y externos, el intercambio de mensajes y la lógica.
BPEL4WS17 es un lenguaje de orquestación de servicios.
Con la orquestación de servicios nos permite diseñar procesos compuestos de otros servicios, dado que una de las partes controla el flujo del proceso. El tipo de proceso puede entenderse como “privado y ejecutable”:
17 http://xml.coverpages.org/BPML-BPEL4WS-WP.pdf
“Privado”: Porque la definición de la lógica del proceso es hecha enteramente por un participante en la interacción.
“Ejecutable”: Porque tiene un comportamiento de conversión de entradas en salidas y tiene efectos en el mundo real.
Entre algunas de las características o propiedades de la orquestación de servicios se pueden citar las siguientes:
La orquestación compone servicios para generar un nuevo proceso y se usa de dos formas distintas: para preparar la información que se intercambia en la ejecución de una coreografía o como la invocación siguiendo unas determinadas reglas a un servicio Web.
La orquestación es un sistema jerárquico en el proceso Web organiza como invocar a otros servicios mediante un flujo de control que determina qué invocar y cuando hacerlo.
Una vez revisado la orquestación de servicios se puede decir que la ejecución de un proceso definido en el lenguaje WS-BPEL18 puede ser ejecutado por un motor BPEL19, que son los lenguajes propios de orquestación de Servicios.
COREAGRAFÍA DE SERVICIOS
La coreografía de Servicios puede concebirse como un proceso público y no ejecutable: es público porque define el comportamiento común y globalmente visible entre los diferentes participantes en una interacción; por otro lado es no ejecutable porque no está pensado para ser llevado a cabo, sino para actuar como un protocolo de negocio que dicta reglas de interacción que deben ser cumplidas por las entidades participantes.
Un proceso Web se considera de coreografía de servicios cuando define las colaboraciones entre más de un servicio para lograr un objetivo común; por lo tanto no se centra en un servicio en particular sino en un objetivo que tiene que cumplir el flujo de un proceso. Un
18 http://www.espaciosoa.net/2007/02/06/ws-bpel-version-20-casi-lista/
19 BELP.- Lenguaje de Ejecución de Procesos de Negocio http://www.gestiopolis.com/delta/term/TER430.html
proceso de coreografía no es controlado por un solo participante de la interacción; la coreografía es mucho más colaborativa, porque permite trazar las secuencias de mensajes que se suceden entre todas las partes participantes del proceso en lugar de centrarse en los mensajes que intercambian los Servicios Web. [17]
Como retroalimentación se puede decir que la coreografía de servicios describe la coordinación de servicios desde un punto de vista colaborativo, entre múltiples partes, donde el control está distribuido. Para describir este tipo de coordinación, se han desarrollado lenguajes como WSCI20 el cual permite describir el orden de invocación y cómo las operaciones pueden ser coreografiadas en el contexto de intercambio de mensajes en el cual los Servicios Web participan; y el estándar del W3C WS-CDL21, que es un lenguaje para describir escenarios de interacción multi-partes (o coreografías). Algunas características importantes de la coreografía se describen las siguientes:
La coreografía se compone de servicios para permitir la colaboración de los participantes mediante el intercambio de mensajes tanto síncronos como asíncronos y que requiere una descripción formal de los protocolos de intercambio de mensajes, lo cual debe estar visible para cada participante que interviene dentro de la coreografía.
Es un sistema entre pares, muchos participantes pueden colaborar, por tanto es posible la existencia de varios flujos de control diferentes.
Se describen interacciones con estado y duraderas.
20 WSCI (Web Service Choreography Interface) lenguaje de descripción de interfaces basado en XML para describir el flujo de mensajes intercambiados por un Web Service participando en interacciones coreografiadas con otros servicios. http://www.w3.org/TR/wsci/
21 WS-CDL(Web Services Choreography Description Languag) Lenguaje para la descripción de Coreografías de Servicios Web .- lenguaje basado en XML que describe la colaboración entre pares peer-to-peer
http://www.ebpml.org/ws_-_cdl.htm
