Jorge E. Giraldo Plaza*; Jaime A. Guzmán**; Demetrio A. Ovalle***

* Magíster en Ingeniería de Sistemas Universidad Nacional de Colombia, Medellín. Docente de la Facultad de Ingenierías del Politécnico Jaime Isaza Cadavid.E-mail: jegiraldp@unal.edu.co, jegiraldp@elpoli.edu.co, Tel: 3197900 ext 476 ]]> ** Ing., Magister en Ingeniería de Sistemas. E-mail: jaguzman@unal.edu.co. Tel: 4255378
*** Ing., Phd en Ingeniería de Informática. E-mail: dovalle@unal.edu.co. Tel: 4255378

La coreografía de servicios web se encarga de la definición de la vista global de un proceso de composición de servicios; en esta definición se identifica los componentes y sus distintas interacciones. La coreografía puede ser definida teniendo en cuenta sus aspectos estáticos y dinámicos. La vista estática está definida por el orden funcional requerido por el servicio compuesto. La vista dinámica se enfoca en las interacciones entre los servicios, ya que a través de estas se intercambia información. En este artículo se presenta un modelamiento a la coreografía de servicios web, con el fin de ser solucionada por medio de definición de restricciones.

The web services choreography defined a global view of web services composition process. In this definition, components and diverse interactions are identified.

The choreography can be defined keeping in mind its statics and dynamic aspects. The static view is defined by the functional order required by the compound service. The dynamic view is focused on the interactions among services, because through them, information is exchanged. This paper shows a modelling to the web services choreography to be solved based in constraints.

INTRODUCCIÓN

La Computación Orientada a Servicios [1] es un paradigma de computación que emplea los servicios web como elementos fundamentales para el desarrollo de aplicaciones distribuidas. Los servicios web —SW— son aplicaciones modulares que ejecutan operaciones sobre la web. En ocasiones es necesario integrar varios de estos a fin de satisfacer peticiones de tipo complejo planteadas por un usuario; este proceso de integración se conoce como composición de servicios web.

En la literatura se encuentran distintas propuestas para el manejo de la coreografía de SW; algunas investigaciones proponen la generación de comportamientos individuales a partir de uno global, representado por una coreografía [4-7]. Propuestas como [8, 9] se enfocan en el análisis de las descripciones semánticas de los servicios desde un punto de vista funcional, es decir, solo se tienen en cuenta las precondiciones y efectos de los servicios.

Por otro lado en [10, 11] se presenta un manejo de la integración de los SW basado en el intercambio de datos sin tener en cuenta las precondiciones y efectos de estos sobre el mundo real.

Las propuestas de coreografía de servicios se han preocupado, unas por el flujo de información representado en entradas y salidas de servicios, y otras, por satisfacer el conjunto de funcionalidades requeridas por el servicio a componer. Por lo anterior es necesaria una propuesta que aborde tanto el manejo de la estructura funcional definida en un modelo de procesos como el flujo de información existente en las interacciones de los servicios componentes. Estos aspectos permiten obtener una descripción completa de la coreografía de servicios desde el punto de vista estático y dinámico.

A partir de la información obtenida en la descripción de la coreografía, es posible definir restricciones sobre las propiedades funcionales y no funcionales de los servicios que permitirán por medio de mecanismos inteligentes como los verificación de restricciones —PVR— [12], un posible manejo automático.

Aunque existen trabajos donde se fusionan la verificación de restricciones con el mundo de los servicios web [13-15], estos no enfatizan en las interacciones presentes entre los servicios, tanto en el nivel de los datos como en el funcional.

Este documento presenta la definición de los componentes de la coreografía de servicios que influyen en su modelo de procesos o requerimientos funcionales, y en su modelo de interacción o dinámico; asimismo se plantea el uso de algoritmos de búsqueda para determinar los servicios apropiados según las restricciones expuestas.

El artículo presenta la siguiente estructura: en la sección 2 se propone un modelamiento de la coreografía de SW teniendo en cuenta aspectos que influyen en una vista dinámica o estática de la coreografía; esta sección finaliza con un caso de estudio aplicado. En la sección 3 se presenta caso de estudio donde es posible visualizar los componentes de la coreografía descritos en la sección 2. Seguido, en la sección 4, se exponen resultados obtenidos y la comparación desde el punto de vista de rendimiento de la propuesta con otras encontradas en literatura; por último en la sección 5 se presentan las conclusiones.

1. COMPONENTES DE LA COREOGRAFÍA DE SERVICIOS WEB

En la figura 1 se ilustran los componentes mencionados. Los círculos representan los SW, identificados cada uno por una letra que representa el rol asignado dentro del proceso de coreografía. Las flechas indican los mensajes intercambiados entre los servicios; el envío y recepción de mensajes constituyen una interacción entre los servicios involucrados.

A continuación se describen con mayor claridad los componentes descritos.

Servicio Web. Un servicio web está definido a partir de su información básica; ésta abarca datos de sus entradas, salidas y la clasificación funcional del servicio. La clasificación es una descripción de la funcionalidad que ofrece el servicio y está en función del servicio y una determinada operación. Las entradas y las salidas de los servicios brindan información acerca del tipo de información intercambiada.

Un servicio indica de manera obligatoria que éste desempeña un rol específico dentro de un proceso de negocio. Por tanto, al realizar el registro del servicio ante el repositorio debe existir al menos una asociación a un rol específico. Por ejemplo, si existe un servicio de traducción de texto, el rol específico que desempeña es el de traductor.

Operaciones. Las operaciones definen las tareas que realiza un determinado SW. Las operaciones acarrean variables, que son los argumentos de invocación del servicio; asímismo una operación bajo un esquema conversacional soporta unos patrones de interacción. Estos últimos se encargan del flujo de información intercambiada por los mensajes que se envían los servicios entre sí. Cada operación contiene un tipo de operación que indica si ésta retorna o no valores, asimismo, si espera que le lleguen algunos datos para su ejecución.

Mensaje. La información intercambiada por los servicios se hace a través de mensajes; siempre existe un emisor y un receptor de un mensaje. El contenido de éste se especifica por medio de las operaciones de los servicios asociados.

Rol. Como se había indicado, dentro de un proceso de negocio existen funcionalidades que se representan por roles y pueden ser asociados SW para realizar dichas funcionalidades. La idea es determinar el servicio apropiado para ser asociado al rol de acuerdo con los requerimientos especiales de intercambio de información propuesto por el proceso de negocio y que abarcan a los roles.

La coreografía de servicios web se caracteriza por definir el orden en el cual un grupo de servicios se intercambia información por medio de mensajes, con el fin de sobrellevar la funcionalidad de un proceso de negocio que requiere la integración de varios servicios web [2]. Esto es posible mediante la elección de los servicios apropiados que garanticen que la definición debe ser desde un punto de vista estructural y dinámico de la coreografía, a partir de la asociación de los servicios al proceso de negocio.

El esquema representado en un diagrama de clases UML expone la relación de los componentes que permiten la descripción de la coreografía. Se ilustra que un SW está asociado a un solo rol. Por su parte, un rol está definido a partir de restricciones sobre la información que este brinda. Un rol se caracteriza por estar asociado a una transición de rol. Lo anterior significa que un rol, una vez sea analizado, permita se analice otro servicio; esta definición de transición de rol permite la manipulación automática en la definición de la coreografía. Por último, un servicio puede tener una o muchas operaciones asociadas a éste las cuales son incluidas en mensajes como parte de la información que acarrea. En la siguiente sección se presenta un caso de estudio en donde se definen los distintos componentes de la coreografía; el caso de estudio se basa en el conocido problema del viajero [16].

2. CASO DE ESTUDIOS

Para ilustrar el desempeño del modelo propuesto, se describe a continuación un caso basado en el dominio de turismo [16], donde se abordan funcionalidades de tiquetes aéreos y hoteles. Desde el punto de vista del proceso de negocio se tienen tres roles: agencia de viajes, línea aérea y el hotel. El problema consiste en que para cada uno de estos se debe buscar el servicio apropiado que pueda llevar a cabo las funcionalidades propuestas por el rol.

El cliente interactúa con la agencia de viajes con el fin de realizar una reserva de tiquetes aéreos y de estadía en un hotel de la ciudad destino, y envía datos iniciales sobre los requerimientos de información. La agencia de viajes interactúa con la línea aérea y el sistema de reservas del hotel. En la figura 3 se sintetiza lo aquí descrito. La etiqueta que tiene cada uno de los nodos representa lo siguiente: C para el cliente, AV para la agencia de viajes, LA para la línea aérea y H para el hotel. Las flechas entre ellos son las conversaciones que se tiene que llevar a cabo para cumplir el objetivo inicial.

Con base en lo propuesto acerca de los componentes de la coreografía de servicios web, se presenta a continuación una notación de cada uno de estos componentes, dando paso en la siguiente sección a su aplicación en el caso de reserva descrito.

a. Servicios. Los servicios se describen así: S=(n,op,Tipo,NumV) la n como el nombre, op es el nombre de la operación, sigue Tipo que representa el tipo de operación, sea éste de enviar o recibir y por último está NumV que significa número de variables de la operación; por cada operación que aparece se repite esta misma información. De acuerdo con lo anterior es solo requerido por parte de las operaciones el nombre, su tipo y el número de variables que maneja.

b. Roles. La notación del Rol es siendo el grupo de restricciones definidas para ese rol y S el servicio que se le asocia. En total son cuatro restricciones y se dividen en categorías de acuerdo con el manejo de información; estas son: tipo de operaciones, número de variables de entrada y de salida, por último están las restricciones de existencia de servicio encargadas de la validación de la asociación entre un servicio y el rol, por tanto en su descripción no es explícita en el rol.

c. Restricciones. Las restricciones se denotan como RS=(Tipo:Valor) el Tipo es la categoría de la restricciones y el Valor es el valor que adopta la restricción.

d. Proceso de negocio. El proceso de negocio se describe en función de los roles y sus restricciones; así pues, es posible abstraer de este un flujo de información que se representa mediante estructuras de control, como las secuencias o los flujos en paralelo. Por defecto se tiene que los flujos en paralelo son secuencias.

e. Mensajes. Los mensajes son importantes en el intercambio de información; así pues, una vez se tengan los servicios asociados a los roles, se definen los mensajes entre estos. De este modo se propone la notación: M = (Or, Ds, op), donde Or es el servicio que emite el mensaje o servicio origen, Ds es el servicio destino, el que recibe el mensaje y op es la operación que acarrea el mensaje. A continuación se exponen los componentes del caso estudio reserva empleando la notación.

a. Servicios. Se presentan los siguientes:

S_AV01 = (Ser_AgenciaViajes, Reserva, Enviar, 1)

S_LA01 = (Ser_LineaAerea, Reserva, Respuesta, 3)

S_H01 = (Ser_hotel, ReservaHabitacion, Respuesta, 3)

El servicio S_AV01 es el servicio agencia de viajes, presenta su nombre, su operación reserva y el tipo de esa operación que es enviar, por último está el número de variables que maneja, es este caso maneja una variable que es su número de identificación. Durante el análisis del servicio se determina si esa variable es un dato de entrada o de salida. La operación reserva envía el dato tanto al servicio S_LA01 y S_H01.

El SW línea aérea 1 se denota de la siguiente manera: S_LA01; la operación que maneja es reserva que es de tipo respuesta y contiene 3 variables en total. Por su parte el servicio web hotel 1 se denota asi: S_H01; contiene una operación llamada reserva/habitación y tiene asociadas a esta 3 variables.

b. Roles. Los roles inicialmente se denotan sin asociar ningún servicio, por tanto, se hace uso del carácter # para denotar la ausencia de un servicio; el sistema como respuesta entrega el nombre notación del servicio que va a ser asociado. A lo anterior se presentan 3 roles, cada uno representando la funcionalidad del caso reserva, al igual que los servicios; estos son los roles: rol agencia de viajes, rol agencia de viajes, rol agencia de viajes.

El rol Agencia de Viajes se denota como y los roles Línea Aérea y Hotel como y respectivamente.

c. Restricciones. Las restricciones se manejan como expresiones sintácticas y por defecto son 4:

R1: num var:3
R2: num var in:2
R3: num var out:1
R4: tipoop:recibir

Estas restricciones hacen parte del rol reserva/vuelo el cual requiere recibir dos parámetros de entrada y se retornar un valor específico. El tipo de la operación es recibir.

La respuesta del sistema comprende la asociación de SW a roles y la definición de mensajes entre estos servicios, para ello se presentan los roles con sus respectivos servicio seguido de los mensajes. Por defecto se determina que los servicios con menor costo en su análisis son aquellos que se encuentran en primer lugar de la lista, por tanto los servicios asociados son:

1. —— El rol Agencia de Viajes se asocia el servicio agencia de viajes 1.

2. —— El rol Línea Aérea se le asocia el servicio línea aérea 1.

3. —— El rol Hotel se le asocia el servicio hotel 1.

e. Mensajes. Los mensajes se definen así: , siendo Or el servicio origen del mensaje y Ds el servicio destino. Como respuesta generada por el sistema existen 3 mensajes; M₁ que está entre el servicio origen S_AV01 (servicio agencia de viajes 1) y el servicio destino S_LA01 (servicio línea aérea). Por último, está el mensaje M₂ se genera entre los servicios S_AV01 y el servicio hotel S_H01 y se utiliza la misma operación, según la notación estos son los mensajes.

M₁ = (S_P01, S_AV01, Rl_Cop1)

M₂ = (S_AV01, S_LA01, Rl_AVop2)

M₃ = (S_AV01, S_H01, Rl_AVop2)

El procedimiento de búsqueda se preocupa de asociar aquellos servicios que pueden interactuar entre si, es decir, si un servicio emite un mensaje el cual contiene una operación de tipo enviar/recibir se debe buscar un servicio par el cual tenga definido una operación de tipo recibir.

3. COMPARACIÓN CON OTROS MODELOS

Las propuestas encontradas acerca de la definición de la coreografía y sus componentes se basan en una deducción de los servicios a partir de un proceso de coreografía, indicando que este es definido con anterioridad. Adicional a esto, los dominios de aplicación son variados, así como dominios bioinformáticos, de turismo y subastas electrónicas.

Desde el punto de vista de la definición de componentes existe ambigüedad, evitando que mecanismos generales de automatización actúen sobre estos con el fin de mejorar el proceso de definición. Esto ocasiona la elección de servicios no apropiados para lo requerido y consecuentemente un intercambio de información poco confiable, donde pueden existir faltas en la integridad de los datos.

Por su parte el modelo de verificación de restricciones planteado facilita la definición de un proceso de coreografía teniendo en cuenta que las descripciones de los servicios no se asocian a aspectos sintácticos ni semánticos. La descripción es abierta con el fin que soporte estos dos tipos de definición. La definición clara y permisible facilita que mecanismos de razonamiento sean aplicables a las descripciones de servicios y otros componentes.

En Aggarwal et al. [14] se presenta una plataforma para la composición de SW dirigida por restricciones que están definidas sobre los aspectos no funcionales de los SW, se tiene en cuenta el costo de ejecución, tiempo de ejecución del proceso y métricas específicas del dominio, entre esas se encuentran los falsos positivos y negativos. Por su parte, la elección del servicio se hace mediante razonamiento semántico que en ningún momento en automático, por el contrario la propuesta de manejar reglas facilita el uso de mecanismos donde se pueda automatizar su razonamiento. En esta investigación se maneja el tiempo de composición pero involucrando aspectos dinámicos que se refieren al orden de intercambio de información entre los componentes.

Thakkar et al. [10] se presenta un marco conceptual para el manejo de la composición, optimización y ejecución de planes para SW en el dominio de la bioinformática. El manejo de los servicios concuerda en la medida de no asociar a ningún tipo de descripción, sea sintáctica o semántica. Para validar esta propuesta se mide el tiempo de composición dependiente del número de servicios involucrados, criterio a utilizar para comparar el modelo propuesto.

Channa et al. [15] se presenta una propuesta interesante del manejo de la verificación de restricciones en la coreografía de SW, las restricciones son definidas mediante una ontología de dominio, representadas en clases, atributos, instancias y relaciones. Por el contrario en esta propuesta investigativa no se tiene en cuenta aspectos semánticos para el descubrimiento de servicios. Sin embargo, la no asociación a ningún tipo de descripción, sea semántica o sintáctica, facilita su uso de manera general en cualquier tipo de dominio. A continuación en las tablas 2 y 3 se comparan distintas propuestas encontradas en la literatura con el modelo propuesto en este trabajo, todo esto desde un punto de vista de rendimiento computacional, se mide la escalabilidad, falsos positivos y negativos. El número varía entre 6 y 9.

4. CONCLUSIONES

Es importante tener en cuenta que la coreografía de servicios web debe ser descrita desde un punto de vista tanto estructural como dinámico. La vista estructural debe encargarse de la definición de los servicios y sus operaciones. Por su parte, la vista dinámica permite el control del flujo de la información por medio del intercambio de mensajes y el uso de los estados de roles.

Es posible representar un comportamiento global dependiente del intercambio de información mediante terminología propia de la coreografía y sus componentes; de este modo se vislumbra la posibilidad de reutilización de la definición global de ésta en problemas con requisitos similares.

Los algoritmos de búsqueda son una herramienta útil para aplicaciones inmersas en ambientes con características propias de la web; esto significa que tanto los servicios, los dominios de aplicación y sus tecnologías asociadas son cambiantes y presentan un comportamiento creciente.

En la revisión literaria realizada a propuestas de investigación orientadas a temas como la coreografía se identifica una clara ambigüedad en la definición de cuáles son los componentes propios de ésta. Por tanto este trabajo propone los componentes y su notación con el fin de que mecanismos inteligentes puedan hacer uso de estos y así lograr una aproximación a la definición automática de la coreografía.

REFERENCIAS

1. G. Alonso, F. Casati, H. Kuno et al., Web Services. Concepts, Architectures and Aplications, Berlin: Springer Verlag, 2004.         [ Links ]

2. C. Peltz, "Web Services Orchestration and Choreography," Computer, vol. 36, no. 10, pp. 46-52, 2003.         [ Links ]

3. N. Kavantzas, D. Burdet, and G. Ritzinger. "Web Services Choreography Description Languages Version 1.0. W3C Working Draft," march, 2007; http://www.w3.org/TR/2004/WD-ws-cdl-10-20040427/.         [ Links ]

4. A. Wombacher, P. Fankhauser, P. Mahleko et al., "Matchmaking for Business Processes Based on Choreographies," International Journal of Web Services, vol. 1, no. 4, pp. 14-32, 2004.         [ Links ]

5. E. Jansen, H. Yang, and S. Helal, "Automated Verification of Proper Choreography Implementation," in 2006 International Symposium on Applications and the Internet (SAINT'06), Phoenix, Arizona, January 23-27, 2006.         [ Links ]

6. M. Hafner, and R. Breu, "From Inter-Organizational Workfows to Process Execution: Generating BPEL from WS-CDL," in ACM / IEEE 8th International Conference on Model Driven Engineering Languages and Systems, Jamaica, 2005.         [ Links ]

7. J. Zaha, M. Dumas, A. Ter et al., "Service interaction modeling: Bridging global and local views," in Proceedings 10th IEEE International EDOC Conference, Hong Kong, 2006.         [ Links ]

8. J. Gekas, and M. Fasli, "Automatic Web Service Composition Using Web Connectivity Analysis Techniques: W3C Workshop," in Frameworks for Semantics for Web Services, Innsbruck, Austria, 2005.         [ Links ]

9. D. Berardi, D. Calvanese, R. Hull et al., "Automatic Composition of Transition-based Semantic Web Services with Messaging," in Proceedings of the 31st VLDB Conference, Trondheim, Norway, 2005, pp. 613-624.         [ Links ]

10. S. Thakkar, J. Ambite, and C. Knoblock, "A data integration approach to automatically composing and optimizing web services," in Proceedings of 2004 ICAPS Workshop on Planning and Scheduling for Web and Grid Services, 2004.         [ Links ]

11. R. Hull, M. Benedikt, D. Christophides et al., "E-services: A look behind the curtain," in Proceedings of ACM Symposium on Principles of Database Systems, 2003.         [ Links ]

12. R. Russell, and P. Norvig, Inteligencia Artificial. Un enfoque Moderno, 2 ed., Madrid: Pearson Education, S.A, 2004.         [ Links ]

13. C. Zhengang, P. Singh, and M. Vouk, "Composition Constraints for Semantic Web Services," in WWW2002 Workshop on Real World RDF and Semantic Web Applications, 2002.         [ Links ]

14. R. Aggarwal, K. Verma, J. Miller et al., "Constraint Driven Web Service Composition in METEOR-S. Services Computing," in IEEE International Conference on (SCC'04), 2004.         [ Links ]

15. N. Channa, L. Shanping, S. Wasim et al., "Constraint Satisfaction in Dynamic Web Service Composition," Asian Journal of Information Technology, vol. 4, pp. 957-961, 2005.         [ Links ]

16. J. A. Rao, "A Survey of Automated Web Services Composition Methods," Department or computer and information science, Norweigan University of science and technology, 2003.        [ Links ]

Recibido: 03/03/2007
Aceptado: 05/10/2009 ]]> 1 2004 2 2003 36 10 10 46-52 3 marc h, 2 4 2004 1 4 4 14-32 5 January 23-27, 2006 Phoenix Arizona 6 2005 7 2006 Hong Kong Hong Kong 8 2005 9 2005 Trondheim 613-624 10 2004 2004 11 2003 12 2004 2 13 2002 14 2004 15 2005 4 4 957-961 16 2003