Embed Size (px)
Citation preview
UNIVERSIDAD NACIONAL DEL CENTRO DE LA PROVINCIA DE BUENOS
AIRES
FACULTAD DE CIENCIAS EXACTAS
Utilización de técnicas de planning con preferencias para
la composición y ejecución de servicios web
Alumno: Renzo Martin Toscani
Director: Dr. Luis Berdun
Co-director: Ing. Sebastian Vallejos
INDICE GENERAL
Índice General
Capítulo 1. Introducción ................................................................................................................ 1
1.1 La tesis .......................................................................................................................................................... 2
Capítulo 2. Estado del arte ............................................................................................................ 4
2.1 Web Services ............................................................................................................................................. 5
2.1.1 SOAP ...................................................................................................................................................... 6
2.1.2 REST ...................................................................................................................................................... 7
2.1.3 SOAP vs REST ..................................................................................................................................... 8
2.2 Lenguajes de descripción de servicios ............................................................................................ 8
2.2.1 WSDL ..................................................................................................................................................... 9
2.2.2 WSMO .................................................................................................................................................. 10
2.2.3 OWL-S ................................................................................................................................................. 11
2.3 Técnicas de planning ............................................................................................................................. 12
2.3.1 AG UCPOP .......................................................................................................................................... 12
2.3.2 JSHOP 2 ............................................................................................................................................... 15
2.4 Composición de servicios .................................................................................................................... 15
2.4.1 Enfoques existentes ...................................................................................................................... 17
2.5 Conclusión ................................................................................................................................................. 17
Capítulo 3. Enfoque .................................................................................................................... 19
3.1 INTERPRETACIÓN Y MODELADO.................................................................................................... 22
3.1.1 Elección de la representación ................................................................................................... 22
3.1.2 Definición de los servicios .......................................................................................................... 23
3.1.3 Representación de los documentos OWL............................................................................. 27
3.1.4 Algoritmo de planeamiento ....................................................................................................... 27
3.1.5 Interpretación de las preferencias .......................................................................................... 28
3.2 PLANEAMIENTO ..................................................................................................................................... 29
3.2.1 Definición de las preferencias ................................................................................................... 29
3.2.2 Definición de las restricciones .................................................................................................. 30
3.2.3 Representación de los servicios ............................................................................................... 31
INDICE GENERAL
3.2.4 Conversión de los servicios hacia el algoritmo de planning ........................................ 32
3.2.5 Generación del plan ....................................................................................................................... 32
3.2.6 Agregado del estado inicial y final .......................................................................................... 33
3.3 EJECUCIÓN ................................................................................................................................................ 34
3.3.1 Interpretación del plan ................................................................................................................ 34
3.3.2 Ejecución del plan .......................................................................................................................... 37
3.4 Conclusión ................................................................................................................................................. 37
Capítulo 4. Diseño e implementación ......................................................................................... 38
4.1 ARQUITECTURA GENERAL DE LA HERRAMIENTA ................................................................. 39
4.2 INTERPRETACIÓN Y MODELADO.................................................................................................... 39
4.2.1 Representación intermedia, dominio de conjuntos ......................................................... 40
4.2.2 Diseño de los servicios web ....................................................................................................... 43
4.2.3 Lectura e interpretación de las ontologías OWL ............................................................... 46
4.2.4 Lectura e interpretación de los documentos OWL-S ....................................................... 47
4.3 PLANEAMIENTO ..................................................................................................................................... 48
4.3.1 Conversión hacia el algoritmo de planning ......................................................................... 49
4.3.2 Generación del plan ....................................................................................................................... 49
4.3.3 Implementación de la traducción hacia el algoritmo de planeamiento .................. 51
4.4 EJECUCIÓN ................................................................................................................................................ 53
4.4.1 Interpretación del plan ................................................................................................................ 54
4.4.2 Representación de los servicios ............................................................................................... 56
4.4.3 Ejecución del plan generado ...................................................................................................... 57
4.5 Conclusión ................................................................................................................................................. 58
Capítulo 5. Resultados experimentales ....................................................................................... 59
5.1 Definición de los casos de estudio ................................................................................................... 59
5.2 Utilización de la herramienta ............................................................................................................ 62
5.3 Pruebas realizadas ................................................................................................................................. 66
5.3.1 Caso de estudio: servicios de clima ........................................................................................ 66
5.3.1.1 Primera prueba ...................................................................................................................... 67
5.3.1.2 Segunda prueba ...................................................................................................................... 68
5.3.1.3 Tercera prueba ....................................................................................................................... 68
5.3.1.4 Resultados ................................................................................................................................ 70
5.3.2 Caso de estudio: servicios de viaje .......................................................................................... 70
5.3.2.1 Primera prueba ...................................................................................................................... 70
5.3.2.2 Segunda prueba ...................................................................................................................... 70
5.3.2.3 Tercera prueba ....................................................................................................................... 71
INDICE GENERAL
5.3.2.4 Resultados ................................................................................................................................ 71
5.4 Conclusión ................................................................................................................................................. 72
Capítulo 6. Conclusiones............................................................................................................. 73
6.1 Limitaciones y trabajos futuros ........................................................................................................ 74
Apéndice A. OWL en detalle ...................................................................................................... 75
A.1 Sintaxis ....................................................................................................................................................... 75
A.1.1 Clases .................................................................................................................................................. 75
A.1.2 Axiomas de clases .......................................................................................................................... 76
A.1.3 Enumeraciones ............................................................................................................................... 76
A.1.4 Restricciones.................................................................................................................................... 76
A.1.5 Intersecciones, uniones y complementos ............................................................................ 77
A.2 Propiedades .............................................................................................................................................. 77
A.2.1 Axiomas de propiedades ............................................................................................................. 77
A.2.2 Características cardinales .......................................................................................................... 78
A.2.3 Características lógicas.................................................................................................................. 78
A.2.4 Individuales ...................................................................................................................................... 78
A.3 Documentos ............................................................................................................................................. 79
A.3.1 Ontology ............................................................................................................................................ 79
A.3.2 Service Profile ................................................................................................................................. 80
A.3.3 Service Grounding ......................................................................................................................... 82
A.3.4 Service Model .................................................................................................................................. 83
A.3.5 Service Process ............................................................................................................................... 83
A.4 Definiciones de las ontologías ........................................................................................................... 84
Bibliografía ................................................................................................................................. 86
INDICE DE FIGURAS
Índice de Figuras
Figura 1.1. Modelo conceptual de la solución propuesta. ............................................................. 3
Figura 2.1. Estructura de una implementación orientada a servicios. ........................................... 5
Figura 2.2. Anatomía de un mensaje SOAP. ................................................................................. 6
Figura 2.3. Infoset XML de un documento WSDL. .................................................................... 10
Figura 2.4. Descripción de un servicio en OWL-S. .................................................................... 12
Figura 2.5. Funcionamiento del algoritmo AG-UCPOP. ............................................................ 13
Figura 2.6. Importancia de las preferencias en los algoritmos de planeamiento. ........................ 14
Figura 2.7. Versión simplificada del algoritmo JSHOP2. ........................................................... 15
Figura 2.8. Diferentes enfoques para la composición de servicios web. ..................................... 16
Figura 3.1. Enfoque de la tesis. ................................................................................................... 20
Figura 3.2. Descripción de las clases en OWL-S. ....................................................................... 24
Figura 3.3. Definición de los perfiles en OWL-S. ....................................................................... 25
Figura 3.4. Descripción de un proceso atómico o servicio en OWL-S. ...................................... 26
Figura 3.5. Definición del grounding de los servicios en OWL-S. ............................................. 26
Figura 3.6. Descripción de los procesos para los servicios en OWL-S. ...................................... 27
Figura 3.7. Representación intermedia de los servicios interpretados. ....................................... 31
Figura 3.8. Plan de orden parcial. ................................................................................................ 34
Figura 3.9. Niveles de ejecución en el plan. ................................................................................ 35
Figura 3.10. Transformación del plan parcial hacia una lista ordenada de acciones. ................. 36
Figura 4.1. Diagrama de paquetes de la herramienta. ................................................................. 39
Figura 4.2. Diagrama de clases contenido en los subpaquetes del paquete Interpreter. .............. 40
Figura 4.3. Conjunto de clases que definen la representación intermedia del dominio. ............. 42
Figura 4.4. Conjunto de clases que definen la representación de las condiciones funcionales. .. 44
Figura 4.5. Conjunto de clases que definen el diseño de los servicios web. ............................... 45
Figura 4.6. Clase OWLParser. .................................................................................................... 47
Figura 4.7. Diagrama de clases correspondiente a la interpretación de los documentos OWL. . 48
Figura 4.8. Diagrama de clases correspondiente a la traducción hacia AG UCPOP. ................. 51
INDICE DE FIGURAS
Figura 4.9. Diagrama de secuencia para la traducción hacia AG UCPOP. ................................. 53
Figura 4.10. Diagrama de clases correspondiente a la interpretación del plan de orden parcial. 55
Figura 4.11. Diagrama de clases correspondiente a la representación de los servicios. ............. 56
Figura 4.12. Diagrama de secuencia correspondiente a la invocación de los servicios. ............. 57
Figura 5.1. Pantalla inicial de la herramienta con el menú desplegado. ..................................... 62
Figura 5.2. Interfaz de la herramienta luego de cargar la ontología y hacer click sobre un
servicio. ....................................................................................................................................... 63
Figura 5.3. Traducción hacia AG UCPOP. ................................................................................. 64
Figura 5.4. Solución otorgada por AG UCPOP. ......................................................................... 65
Figura 5.5. Invocación de los servicios. ...................................................................................... 65
Figura 5.6. Solución para la primera prueba de servicios del clima. ........................................... 67
Figura 5.7. Solución para la segunda prueba de servicios del clima. .......................................... 68
Figura 5.8. Solución para la tercera prueba de servicios del clima. ............................................ 69
Figura A.1. Ejemplo del contenido del archivo Ontology. ......................................................... 80
Figura A.2. Descripción del perfil de un servicio en el archivo Profile. ..................................... 82
Figura A.3. Ejemplo del contenido del archivo Grounding. ....................................................... 83
Figura A.4. Ejemplo de la asociación de un servicio con su respectivo grounding. ................... 83
INDICE DE TABLAS
Índice de Tablas
Tabla 2.1. Características de los servicios REST y SOAP. ........................................................... 8
Tabla 5.1. Descripción de los servicios en el caso de estudio de los servicios del clima de una
ciudad. ......................................................................................................................................... 60
Tabla 5.2. Descripción de los servicios en el caso de estudio correspondiente a los servicios de
viajes. .......................................................................................................................................... 61
Tabla 5.3. Representación de las variables utilizadas por los servicios de las tablas 5.1 y 5.2. .. 62
Tabla 5.4. Resultados de las pruebas correspondiente al primer caso de estudio. ...................... 70
Tabla 5.5. Resultados de las pruebas correspondiente al segundo caso de estudio. .................... 71
1
Capítulo 1
Introducción
Un servicio web es una tecnología que permite intercambiar datos entre dos
aplicaciones mediante el uso de protocolos y estándares abiertos. Los servicios web en
general ofrecen funciones básicas o simples que solucionan problemas puntuales. La
composición de servicios se da cuando se necesita solucionar problemas mayores
utilizando sucesivas invocaciones a otros servicios.
La composición automática de servicios web es una problemática actual. Debido a la
continua creación y actualización de estos servicios, la composición manual de nuevos
servicios se vuelve impracticable (Booth et al., 2004). Distintas alternativas surgieron
con el objetivo de automatizar el proceso de composición de servicios web. Entre estas
alternativas se encuentra el uso de algoritmos de planning (Sirina et al., 2004).
Planning es una rama de la IA que tiene como objeto la creación de secuencias de
acciones que dado un estado inicial conocido permiten alcanzar un estado final deseado
(Weld 1994). Los algoritmos de planning se encargan de elegir y ordenar las acciones
a realizar para lograr determinado objetivo a partir de cierto estado inicial. Estos
algoritmos son en su mayoría de propósito general y pueden aplicarse en infinidad de
dominios. En nuestro caso particular, nos permiten componer distintos servicios para
poder alcanzar el servicio buscado. Algunos algoritmos de planning permiten
adicionalmente indicar preferencias o distintos criterios extras a la hora de realizar el
plan de ejecución. Dos algoritmos de estas cualidades son Ag-Ucpop (Berdun et al.,
2011) y Shop2 (Nau et al., 2003). Por un lado, en Gerevini et al., 2005, el algoritmo fue
diseñado para interactuar con el estado mental de agentes. Por esta razón permite
definir actitudes mentales (preferencias y objetivos) mediante lógica proposicional.
Estas actitudes impactan en la forma en que el algoritmo alcanza la solución final. Por
el otro lado, en Nau et al., 2003, el algoritmo interpreta el lenguaje de descripción PDDL.
En todos los casos estos algoritmos mantienen su premisa básica, es decir que permiten
seleccionar y ordenar las acciones para alcanzar el estado final planteado, pero lo hacen
buscando soluciones que no solo resuelven el problema, sino también que se adecuen
a lo pretendido.
CAPITULO 1. INTRODUCCION
2
En nuestro caso particular, cómo es posible encontrar diferentes formas en que se
compongan los servicios para que cumplan con los requisitos del usuario, es necesario
algún mecanismo para elegir cual servicio va a tomar parte de la solución y cuál no. En
este punto los algoritmos de planning con preferencias hacen la diferencia, permitiendo
al usuario guiar al algoritmo para encontrar una solución más acorde a sus requisitos
(por ejemplo, priorizar el uso de servicios según propiedades como disponibilidad, costo,
tiempo de respuesta, etc). Por lo tanto, dicho algoritmo seleccionará de un conjunto de
servicios, el que mejor cumpla con las preferencias del usuario.
Hoy en día la composición de servicios web mediante algoritmos de planning es objeto
de estudio, ya que cuando un servicio atómico no puede satisfacer los requisitos del
usuario debería existir la posibilidad de combinar de forma inteligente los servicios
existentes con el objetivo de satisfacer los requerimientos solicitados (Ordoñez et al.,
2012) (Tabatabaei et al., 2008). Esto permitiría obtener soluciones a problemas más
complejos invocando servicios existentes.
1.1 La tesis
El objetivo del trabajo propuesto consiste en el diseño y desarrollo de una herramienta
que permita componer y ejecutar servicios complejos a partir de un conjunto
determinado de servicios web más simples. Para tal fin se utilizaron algoritmos de
planning que aceptan preferencias del usuario para obtener no solo el servicio sino
también la calidad buscada por el usuario. La herramienta se complementa con el
soporte necesario para invocarlos y obtener el resultado de la composición de los
servicios.
El enfoque propuesto se presenta en la Figura 1.1. En esta se puede observar que la
entrada consiste en:
El conjunto de servicios web disponibles para realizar la composición.
La funcionalidad deseada en el servicio web a componer.
Las preferencias del usuario sobre los servicios web a utilizar en la composición.
Estos datos son utilizados en la etapa de Planeamiento y composición para generar un
plan de ejecución de los servicios web provistos que cumplan los requisitos del usuario.
Este plan será entrada del componente de Ejecución de servicios. Este componente
ejecuta los servicios según el plan obtenido y los datos requeridos por los servicios a
invocar, los cuales son ejecutados para dar lugar al resultado final.
CAPITULO 1. INTRODUCCION
3
Finalmente, la herramienta es puesta a prueba utilizando un conjunto de servicios base.
Durante las evaluaciones se utilizaron distintas preferencias sobre los servicios a utilizar
para lograr obtener la composición de servicios deseada.
De esta forma se logra medir la factibilidad de la herramienta y el impacto del uso de
preferencias en el resultado de la composición.
Figura 1.1. Modelo conceptual de la solución propuesta.
4
Capítulo 2
Estado del arte
Un servicio web es una tecnología que permite intercambiar datos entre dos
aplicaciones mediante el uso de protocolos y estándares abiertos1. Este tipo de
tecnologías posee dos grandes ventajas: En primer lugar, la adopción de estándares
permite la interoperabilidad entre distintas aplicaciones independientemente de las
plataformas sobre las que se encuentran. En segundo lugar, distintos servicios web
provistos por diferentes proveedores pueden ser combinados, componiendo así un
servicio web más complejo (Kuter et al., 2005).
Hoy en día los usuarios demandan cada vez más información a lo largo de diferentes
plataformas lo que hace a los servicios Web más prácticos. Esto se debe a que pueden
aportar gran independencia entre la plataforma que usa el servicio Web y el servidor
que contiene toda la información requerida. La siguiente figura muestra gráficamente
dicho esquema:
1 https://www.w3c.es/Consorcio/about-w3c.html
CAPITULO 2. ESTADO DEL ARTE
5
Figura 2.1. Estructura de una implementación orientada a servicios.
Los servicios web en general ofrecen funciones básicas o simples que solucionan
problemas puntuales. La composición de servicios se da cuando se necesita solucionar
problemas mayores utilizando sucesivas invocaciones a servicios. Esta composición
puede realizarse de forma manual, pero la continua creación y actualización de los
servicios web, hace que esto sea impracticable (Booth et al., 2004). Distintas alternativas
surgieron (Guillermo Rodríguez et al., 2015) para la composición de servicios web de
manera automática, entre ellas, el uso de algoritmos de planning (Sirina et al., 2004).
2.1 Web Services
El objetivo principal de los servicios web es lograr la interoperabilidad entre distintas
aplicaciones distribuidas y heterogéneas para combinar la funcionalidad de varios
servicios web (Alonso et al., 2004). A continuación se describe y estudia algunos de los
diferentes servicios web que existen y son utilizados hoy en día.
CAPITULO 2. ESTADO DEL ARTE
6
2.1.1 SOAP
SOAP es un protocolo ligero destinado a intercambiar información estructurada en un
entorno descentralizado y distribuido. Utiliza XML para definir un marco extensible de
mensajería proporcionando así una construcción de mensajes que pueden ser
intercambiados a través de una variedad de protocolos subyacentes. El marco ha sido
diseñado para ser independiente de cualquier modelo de programación en particular y
semántica específica.
Dos de los principales objetivos de diseño para SOAP son la simplicidad y extensibilidad.
SOAP intenta cumplir estos objetivos mediante la omisión de las características que se
encuentran a menudo en los sistemas distribuidos. Tales características incluyen, pero
no se limitan a "fiabilidad", "seguridad", "correlación", "ruteo" y "patrones de intercambio
de mensajes" (MEPS).
SOAP proporciona un mecanismo estándar para empaquetar un mensaje. Este se
compone de un sobre que contiene el cuerpo del mensaje y cualquier información de
cabecera que se utiliza para describir el mensaje. A continuación se da un ejemplo:
Figura 2.2. Anatomía de un mensaje SOAP.
A su vez, los mensajes pueden componerse de entradas, salidas y mensajes de error
que puedan surgir durante la invocación al mismo, siendo la primera de estas la única
que debe incluirse en todas las posibles combinaciones. A continuación se da un
ejemplo de algunos de los tipos de combinaciones que pueden ser utilizadas.
Únicamente mensaje de entrada:
<operation name="myOperation">
<input message="tns:myInputMessage"/> </operation>
Mensaje de entrada y salida:
CAPITULO 2. ESTADO DEL ARTE
7
<operation name="myOperation"> <input message="tns:myInputMessage"/> <output message="tns:myOutputMessage"/> </operation>
Mensaje de entrada y retorno de error:
<operation name="myOperation"> <input message="tns:myInputMessage"/> <fault="tns:myFaultMessage"/> </operation>
Mensaje de entrada, salida y retorno de error:
<operation name="myOperation"> <input message="tns:myInputMessage"/> <output message="tns:myOutputMessage"/> <fault="tns:myFaultMessage"/> </operation>
2.1.2 REST
REST (Representational State Transfer), es un estilo de arquitectura de software
dirigidos a sistemas distribuidos como lo es la Web y se refiere específicamente a una
colección de principios, los cuales resumen la forma en que los recursos son definidos
y diseccionados, para el diseño de arquitecturas en red. Este término es utilizado en su
mayoría para describir a cualquier interfaz que transmite datos específicos de un domino
sobre HTTP sin una capa adicional, como lo hace SOAP.
REST define un conjunto de principios de la arquitectura por la cual se pueden diseñar
servicios web que, a diferencia de los servicios SOAP, se centran en los recursos del
sistema, incluyendo cómo los estados de los recursos se tratan y se transfieren a través
de HTTP por una amplia gama de clientes. Una implementación concreta de un servicio
web REST sigue a cuatro principios básicos de diseño:
Utilizar métodos HTTP de forma explícita (GET, POST, DELETE)
No poseer estado
Exponer la estructura de directorios de forma similar a los URI2.
La transferencia de la información debe estar representada por XML, JSON, o
ambos
En este tipo de servicio cada mensaje HTTP contiene toda la información necesaria para
comprender la petición. Como resultado, ni el cliente ni el servidor necesitan recordar
2 https://www.w3.org/Addressing/URL/uri-spec.html
CAPITULO 2. ESTADO DEL ARTE
8
ningún estado de las comunicaciones entre mensajes. Sin embargo, en el mundo real
muchas aplicaciones basadas en HTTP utilizan cookies y otros mecanismos para
mantener el estado de la sesión por cuestiones de seguridad.
2.1.3 SOAP vs REST
Mientras que SOAP ha sido el enfoque dominante de las interfaces de servicios web
durante mucho tiempo, REST está ganando rápidamente y ahora representa más del
70% de las API públicas. Esto se debe a que con REST + JSON es más fácil de
interactuar, particularmente para API públicas, pero SOAP todavía se prefiere para
casos de uso específicos.
A continuación se enumeran y comparan algunas de las características de ambos tipos
de servicios:
REST SOAP
Pocas operaciones con muchos recursos Muchas operaciones con pocos recursos
Se centra en la escalabilidad y rendimiento a gran escala para sistemas distribuidos
Se centra en el diseño de aplicaciones distribuidas
HTTP GET, HTTP POST, HTTP PUT, HTTP SMTP, HTTP POST
XML auto descriptivo Tipado fuerte, XML Schema
Síncrono Síncrono y asíncrono
HTTPS WS SECURITY
Comunicación punto a punto y segura Comunicación origen a destino seguro
Tabla 2.1. Características de los servicios REST y SOAP.
2.2 Lenguajes de descripción de servicios
En la teoría de la informática, un lenguaje consiste en un conjunto (posiblemente infinito)
de oraciones, y cada oración es una cadena finita de símbolos o caracteres literales.
Una especificación de lenguaje debe por lo tanto definir el conjunto de oraciones en ese
idioma, y, para ser útil, también debe indicar el significado de cada oración.
Debido a que los protocolos de comunicación y los formatos de los mensajes que se
intercambian están estandarizados en la web, se vuelve cada vez más posible e
CAPITULO 2. ESTADO DEL ARTE
9
importante ser capaz de describir las comunicaciones de alguna manera estructurada.
Los lenguajes de descripción de servicios buscan estandarizar la forma de
comunicación, es decir, los requisitos del protocolo y los formatos de los mensajes
necesarios para interactuar con los servicios.
A continuación se describirán algunas de las diferentes formas de descripción de
servicios.
2.2.1 WSDL
WSDL aborda dicha necesidad mediante la definición de una gramática XML para
describir servicios de red como colecciones de puntos finales de comunicación capaces
de intercambiar mensajes. Las definiciones de servicios WSDL proporcionan
documentación para sistemas distribuidos y sirven como una receta para la
automatización de los detalles involucrados en la comunicación de aplicaciones3.
Esto se lleva a cabo mediante la definición de varios tipos de elementos relacionados
entre sí. Los más relevantes son los siguientes:
Messages: Permite definir los elementos de un mensaje, los cuales tienen
nombre y tipo, entre otros posibles parámetros.
Types: Permite definir los tipos de datos utilizados en los mensajes a partir de
los tipos definidos por XML.
Port Types: Indica las operaciones permitidas por un puerto y los mensajes que
se intercambian a través del mismo.
Bindings: Especifica los protocolos de comunicación usados por cada puerto.
Service: WSDL define a los servicios como un conjunto de puertos y direcciones
con las cuales se deben intercambiar los mensajes.
El diagrama siguiente proporciona una descripción general del infoset (conjunto de
información) XML para un documento WSDL.
3 https://www.w3.org/TR/wsdl#_wsdl
CAPITULO 2. ESTADO DEL ARTE
10
Figura 2.3. Infoset XML de un documento WSDL.
2.2.2 WSMO
Web Service Modeling Ontology es otra forma de representación ontológica que permite
la descripción semántica de servicios web en varios aspectos. Dichos aspectos fueron
tomados y refinados del trabajo realizado por Dieter Fensel et al., (2002) denominado
“Web Service Modeling Framework”.
En WSMO, las ontologías son la clave para la vinculación de la semántica del mundo
real y se encuentran acordadas por comunidades de usuarios. Una ontología es una
especificación explícita y formal de una conceptualización compartida (T. Gruber, 1993).
A partir de esta definición conceptual se desea extraer los componentes esenciales que
definen una ontología. Con el fin de capturar las propiedades semánticas de las
relaciones y conceptos, una ontología ofrece, generalmente, un conjunto de axiomas
que son expresiones en un lenguaje lógico. El siguiente listado consiste en la definición
y descripción de los elementos más importantes que posee WSMO:
Ontología: Provee la terminología utilizada por otros elementos.
Metas: Estados a los cuales se debe llegar mediante la utilización del servicio
web.
CAPITULO 2. ESTADO DEL ARTE
11
Descripción: Descripciones de los servicios web que define varios aspectos del
mismo.
Mediadores: Resuelven posibles problemas de interoperabilidad.
WSMO toma estos aspectos en conjunto con otros para terminar de definir el esquema
de la ontología de los servicios web. Junto con la introducción de los principales
elementos de WSMO, se proporciona la sintaxis del lenguaje de lógica formal WSML
(Web Service Modeling Language). La semántica y subconjuntos computacionalmente
manejables de este lenguaje lógico se definen y se discuten en su documento de
especificación4.
2.2.3 OWL-S
OWL-S (previamente conocido como DAML-S), que extiende de OWL (Ontology Web
Language), es un lenguaje que permite la descripción de servicios web de manera
ontológica. Esto quiere decir que permiten la creación de ontologías para cualquier
dominio y la creación de instancias de estas ontologías en la descripción de los sitios
web específicos. Este tipo de lenguaje puede construir y determinar de manera
automática secuencias lógicas con el objetivo de descubrir, invocar y componer
servicios web.
Para hacer uso de un servicio web es necesario un agente que pueda interpretar la
descripción del servicio, así como los medios por los cuales va a ser accedido. La
estructura y los mecanismos de OWL proporcionan un lenguaje de representación
compatible con lo antes mencionado.
OWL-S describe al servicio web en tres partes:
Service Profile: El perfil del servicio describe qué organización provee el servicio
y las características del mismo (como disponibilidad, calidad, costo, etc).
Service Model: El modelo del servicio es la parte que se encarga de describir el
servicio web como procesos. El modelo puede describir tanto procesos atómicos
que correspondan a los servicios web, como procesos compuestos que
corresponda con un flujo de ejecución formado por otros procesos.
Service Grounding: La especificación de cómo interpretar un servicio describe
cómo se debe ejecutar el mismo. En concreto, esta parte realiza una conexión
entre el Service Model y otro lenguaje que describa sintácticamente al servicio
web.
4 https://www.w3.org/Submission/WSMO/.
CAPITULO 2. ESTADO DEL ARTE
12
Gráficamente, un servicio descrito por OWL-S se compone de la siguiente manera:
Figura 2.4. Descripción de un servicio en OWL-S.
A diferencia de WSDL, OWL-S maneja los tipos que son utilizados por el Grounding en
forma de clases. Esto permite realizar jerarquías para ser utilizadas en las entradas y
los retornos de los servicios en vez de utilizar tipos primitivos. Con esto se logra una
mejor compatibilidad entre servicios con tipos de entradas y salidas compatibles.
2.3 Técnicas de planning
En la inteligencia artificial, “planning” originalmente significaba la búsqueda de una
secuencia de operadores lógicos o acciones que transforman un estado inicial del
mundo en un estado objetivo deseado (Steven M. LaValle, 2006). En el caso particular
de este trabajo, las técnicas serán utilizadas para encontrar una secuencia de servicios
que en su estado final cumplan con los requisitos dados por el usuario.
2.3.1 AG UCPOP
Ag Ucpop parte del algoritmo Ucpop el cual extiende del algoritmo POP (Partial Order
Planning). En este algoritmo las acciones se componen de tuplas que poseen entradas,
efectos condicionales, condiciones previas y efectos universalmente cuantificados
(Weld et al., 1992). Los planes generados no tienen un orden total, sino que existen links
causales que le dan orden a cada par de acciones, e indica el motivo del mismo. Estos
planes reciben el nombre de plan parcial.
CAPITULO 2. ESTADO DEL ARTE
13
El algoritmo en cuestión posee una agenda de objetivos escritos en forma de efectos
deseados por el usuario y un conjunto de acciones que pueden ser aplicadas. En cada
paso se selecciona un objetivo y una acción que cumpla el mismo (es decir, que tenga
el objetivo como postcondición). Luego quita de la agenda el objetivo cumplido por la
acción y agrega las precondiciones de la misma. Los pasos se repiten hasta que la
agenda se vacíe. De esta forma se logra obtener una secuencia ordenada de acciones
que cumpla con la agenda de objetivos dada. Este enfoque se ve reflejado en la figura
2.5.
Figura 2.5. Funcionamiento del algoritmo AG-UCPOP.
Como el algoritmo comienza por el estado final y realiza acciones hasta llegar al estado
inicial, se dice que es un algoritmo de planning inverso. El mismo es simple de
comprender, pero tiene algunas desventajas. Por ejemplo, al agregar una nueva acción
al plan, el algoritmo desconoce cuál es el estado del mundo ya que no sabe cuáles son
CAPITULO 2. ESTADO DEL ARTE
14
las acciones que precederán a la acción recién agregada. Como consecuencia, las
acciones en este tipo de algoritmo no tienen permitido modificar el estado del mundo ni
agregar nuevos hechos al mismo.
Ag Ucpop fue diseñado para interactuar con el estado mental de agentes. Por esta razón
permite definir actitudes mentales (preferencias y objetivos) mediante lógica
proposicional. Estas actitudes impactan en la forma en que el algoritmo alcanza la
solución final. Por el otro lado, en “SHOP2: An HTN Planning System” (Dana Nau et al.,
2003), el algoritmo interpreta el lenguaje de descripción PDDL descrito en “Plan
Constraints and Preferences in PDDL3, The Language of the Fifth International Planning
Competition” (Alfonso Gerevini et al., 2005). PDDL incorpora en su versión 3.0
restricciones y preferencias de estado que permiten al usuario interactuar con el
algoritmo para obtener una solución más acorde a los requisitos externos involucrados.
Las restricciones de estado son expresiones lógicas que deben ser ciertas durante la
ejecución del plan en cuestión. Mientras que las preferencias son restricciones en forma
de expresiones lógicas (similares a las restricciones de estado) que definen el orden de
las acciones a considerar para el plan actual en caso de que varias de estas cumplan
con los requisitos.
En el trabajo realizado por Luis Berdun et al. (2011) se puede apreciar cómo afecta el
estado mental del agente de un algoritmo de planeamiento a la solución obtenida,
específicamente mediante el uso de preferencias. En este trabajo se pudo concluir que
la introducción de preferencias al algoritmo de planeamiento mejoró notoriamente los
resultados obtenidos. A continuación, en la figura 2.6, se puede ver cómo el uso de las
preferencias cambia el orden en la lista de acciones del algoritmo de planeamiento.
Figura 2.6. Importancia de las preferencias en los algoritmos de planeamiento (Luis Berdun et al., 2011).
CAPITULO 2. ESTADO DEL ARTE
15
2.3.2 JSHOP 2
JSHOP2 es una implementación en Java de SHOP2, un algoritmo HTN de planning. Los
algoritmos HTN proporcionan una forma adecuada de planificar recursos cuando existe
de antemano una información jerárquica de la estructura del dominio. Las acciones
tienen precondiciones y efectos al igual que en UCPOP, pero los problemas son vistos
de otra manera debido a que el mismo no intenta buscar una secuencia de acciones
que satisfagan al plan, sino que la solución es una nueva acción compuesta por otras
acciones. El plan puede ser visto como un conjunto de sub-planes más pequeños e
independientes entre sí.
Este algoritmo va generando el plan en el orden final del mismo. En cada paso considera
las acciones aplicables en ese momento del planning y selecciona una de ellas. Esta
manera de planificación lineal le permite al algoritmo conocer el estado del mundo al
momento de seleccionar una acción y modificar el estado del mismo.
Figura 2.7. Versión simplificada del algoritmo JSHOP2.
Si bien el algoritmo permite la definición de preferencias, estas no se tienen en cuenta
a la hora de ejecutar la formulación del plan, por lo que se podría considerar que el
algoritmo no posee realmente preferencias.
2.4 Composición de servicios
CAPITULO 2. ESTADO DEL ARTE
16
Los servicios web ofrecen en general funciones básicas o simples, las cuales se pueden
componer para ofrecer servicios más complejos. Como se pudo apreciar en Guillermo
Rodríguez et al. (2015) distintas alternativas surgieron con el objetivo de automatizar el
proceso de composición de servicios web. Entre estas alternativas se encuentra tanto
el uso de algoritmos de planning como el de agentes. Las diferentes alternativas pueden
ser separadas en diferentes categorías (o enfoques) según indica la figura 2.7.
Figura 2.8. Diferentes enfoques para la composición de servicios web (Portchelvi et al., 2012).
Los dos enfoques más grandes que se ven reflejados en la figura 2.7 corresponden a la
composición de servicios de forma estática basada en la sintaxis de dichos servicios y
la composición automatizada basada en la semántica de los servicios. Dentro de cada
una de estas categorías se pueden observar otros dos enfoques, pero el que realmente
nos interesa para el desarrollo de esta tesis es el enfoque automatizado mediante
algoritmos de planning basado en metas a cumplir para resolver el problema.
Como se mencionó en la sección 2.3, existen varios algoritmos de planning con los que
se puede llevar a cabo el planeamiento para la composición de los servicios. Sin
embargo UCPOP tiene una ventaja respecto al resto y es que él mismo acepta
preferencias. Estas preferencias nos permiten priorizar los servicios incluidos para
elegir, en caso de encontrar más de uno que satisfaga las condiciones, el servicio que
más nos convenga de acuerdo a nuestras necesidades.
CAPITULO 2. ESTADO DEL ARTE
17
2.4.1 Enfoques existentes
Hasta el momento han surgido varios enfoques diferentes para la composición
automática de servicios web. Distintas universidades han estado trabajando sobre el
tema en cuestión.
En este contexto, la investigación realizada por Guillermo Rodríguez et al. (2015)
expone una comparación y categorización de 69 trabajos existentes sobre composición
de servicios web, que se encuentran comprendidos entre los años 2002 y 2014. En dos
de estos trabajos se permite el uso de preferencias de manera directa, es decir, el
usuario debe especificar explícitamente al algoritmo qué servicio debe tener mayor
prioridad. El primero, corresponde a un trabajo desarrollado por Suraci et al. (2007), en
el cual se diseñó una arquitectura que utiliza OWL para modelar semánticamente la
descripción y el modelo de información de los servicios web.
El segundo, corresponde a un trabajo realizado por la universidad de Maryland, USA.
En esta investigación, se desarrolló un algoritmo capaz de traducir descripciones de
servicios del lenguaje OWL en objetos de dominio JSHOP2 para, posteriormente,
realizar el planeamiento y la ejecución de los servicios web. Dicho enfoque se puede
apreciar en Evren Sirina et al. (2004).
Por otro lado, existe otro enfoque abordado por Naiwen Lin (2008) que trata de incluir a
la composición automática de servicios, el uso de preferencias. En éste, se desarrolla
un algoritmo que permite utilizar preferencias del usuario para realizar el planeamiento
de servicios. Sin embargo, la herramienta no permite llevar a cabo la ejecución de los
mismos.
2.5 Conclusión
En el presente capítulo se han introducido los conceptos de servicios web, se han
presentado distintos lenguajes de descripción para los mismos y las posibles técnicas
de planning para llevar a cabo su composición. Además, se ha presentado el estado de
las herramientas e investigaciones existentes relacionadas a la composición de
servicios.
Si bien las investigaciones realizadas hasta el momento proporcionan un antecedente
para la composición de servicios, no existen trabajos que permitan realizar la ejecución
de los servicios en conjunto con la introducción de preferencias. Adicionalmente, no hay
muchas herramientas amigables que se puedan utilizar para la composición dinámica
de los servicios utilizando preferencias, dado que la gran mayoría de estas herramientas
CAPITULO 2. ESTADO DEL ARTE
18
realizan la composición de los servicios de manera estática teniendo el usuario que
definir la lista de servicios que desean ser invocados.
Debido a esto, en el siguiente capítulo se propone un enfoque que aborda esta cuestión
pero permitiendo al usuario especificar, además de preferencias directas, las
propiedades de los servicios sobre las cuales el usuario puede establecer su
preferencia. Este enfoque implica la realización de una herramienta capaz de interpretar,
componer e invocar servicios web, permitiendo al usuario la introducción de preferencias
sobre dichos servicios.
19
Capítulo 3
Enfoque
Hoy en día, con el crecimiento del uso de las buenas prácticas a la hora de definir una
arquitectura de software, los servicios web son cada vez más utilizados para abstraer el
acceso a la lógica del negocio de la misma. Estos servicios suelen ser fácilmente
accesibles desde cualquier dispositivo mediante simples invocaciones a protocolos
específicos (HTTP, SOAP) lo cual permite, por ejemplo, desacoplar la vista de la lógica
del negocio en las distintas plataformas para las cuales se implemente la solución o,
incluso, lograr la interoperabilidad entre diferentes lógicas del negocio de manera
ordenada. Esta interoperabilidad entre diferentes lógicas de negocio se denomina
composición de servicios web (Web Service Composition).
En este sentido, la composición de servicios se utiliza para solventar problemas que un
único servicio no puede solucionar. Esta tarea implica, dada una descripción de alto
nivel de un objetivo, realizar la selección automática, composición e interoperación de
servicios web compatibles para llevar a cabo una tarea más compleja.
Existen varias maneras de obtener la selección automática de los servicios para lograr
la compatibilidad entre los mismos, como interacciones entre agentes, algoritmos de
Planning, etc. Los algoritmos de Planning se encargan de obtener una solución o
secuencia finita de acciones partiendo de un estado inicial, un conjunto de acciones
posibles y un objetivo específico. En nuestro caso particular se utilizará un algoritmo que
permita la introducción de preferencias de usuario para, de esta forma, poder obtener y
comparar distintas soluciones. Las preferencias del usuario servirán como entrada al
algoritmo y permitirán ponderar la importancia de una acción sobre otra.
En esta tesis se desarrolla un proceso que permite realizar la composición automática
de servicios. El proceso permite interpretar, modelar, planear (permitiendo la
introducción de preferencias de usuario) y ejecutar los servicios web de manera
conjunta.
CAPITULO 3. ENFOQUE
20
Los principales problemas abordados de la tesis consisten en:
Interpretar y modelar los servicios de forma tal que el algoritmo de planning logre
identificar las entradas y salidas de los servicios compatibles.
Planear los servicios que deben ser ejecutados mediante la introducción de
preferencias al algoritmo de planning. Esto permite distinguirlos de acuerdo a
características tales como disponibilidad, costo, etc. para obtener una solución
acorde a los requisitos del usuario.
Ejecutar los servicios que se encuentran en los planes generados por el
algoritmo de planning.
La siguiente figura muestra un esquema conceptual del enfoque.
Figura 3.1. Enfoque de la tesis.
Para poder inferir los servicios que son compatibles entre sí, es necesario definir una
manera de interpretar la semántica de dichos servicios. El componente encargado de
realizar esta tarea es el Interpretador de semántica. En este punto es donde se utiliza la
composición de servicios de manera semántica (Semantic Web Service Composition).
SWSC proporciona una descripción de los servicios a nivel de proceso que, además de
CAPITULO 3. ENFOQUE
21
información funcional, modela las condiciones previas y posteriores de los procesos
para que la evolución del dominio pueda inferirse lógicamente (V. Portchelvi et al., 2012).
De esta forma, el componente toma como entrada la descripción de los servicios web
para procesar las mismas y dar lugar al Modelo del plan. El siguiente objetivo es
transformar la semántica generada en acciones que el Algoritmo de Planning sea capaz
de interpretar, donde cada acción será el equivalente a un servicio. Las acciones
resultantes van a contener precondiciones y postcondiciones que van a estar mapeadas
a las entradas y salidas de cada uno de los servicios y que serán utilizadas por el
Algoritmo de Planning.
Por otro lado, para poder ejecutar el Algoritmo de Planning es necesario que el usuario
establezca las variables de entrada del mismo. En primer lugar necesitaremos que se
definan las preferencias para cada uno de los distintos servicios. El Identificador de
preferencias es el encargado de identificar y traducir los requisitos del usuario en
preferencias que PDDL pueda utilizar durante la ejecución del Algoritmo de Planning.
Estas preferencias nos permiten guiar al algoritmo hacia una solución acorde a lo que
el usuario requiera. Si bien este parámetro es opcional, el objetivo principal de la tesis
es analizar el impacto y la variación en los planes generados cuando las preferencias
son agregadas.
En segundo lugar, el usuario deberá establecer el objetivo deseado, es decir, el conjunto
de variables a satisfacer mediante la ejecución de los servicios web. En este caso, el
Determinador del objetivo será el encargado de traducir y transformar el objetivo dado
por el usuario en el Estado Final para que el Algoritmo de Planning sea capaz de
interpretarlo.
Una vez obtenido todos los datos de entrada, la secuencia de acciones (servicios a
ejecutar) y el objetivo, se puede proceder a la ejecución de los servicios con el fin de
obtener el resultado deseado por el usuario.
El Algoritmo de Planning es el encargado de realizar la planificación de las acciones en
base a las entradas y preferencias definidas por el usuario para generar la composición
automática de los servicios. El resultado del algoritmo será el Plan propuesto, es decir,
un conjunto de acciones ordenadas que permiten arribar al objetivo planteado por el
usuario. Este resultado puede ser visto como una secuencia ordenada de acciones lista
para ejecutar.
Una vez obtenido el Plan propuesto necesitaremos ejecutarlo para obtener los valores
requeridos por el usuario. El componente encargado de llevar a cabo esta tarea es el
Invocador de Servicios. El mismo tomará como entradas el Plan propuesto generado
por el Algoritmo de Planning en conjunto con los servicios disponibles para realizar la
ejecución de los mismos y así obtener el resultado final de la composición. Por último,
CAPITULO 3. ENFOQUE
22
se ejecutan todas las acciones y, una vez que se hayan ejecutado exitosamente, se
retorna el resultado al usuario.
En las secciones siguientes se muestra en detalle cada componente interno de la
aplicación mediante un ejemplo conductor. El ejemplo consiste en un conjunto de
servicios y preferencias dadas por un usuario en particular con la finalidad de obtener el
clima de una ciudad particular.
3.1 INTERPRETACIÓN Y MODELADO
En la siguiente sección se presentan las diferentes sub-etapas que se incluyen en el
proceso de interpretación y modelado.
3.1.1 Elección de la representación
La descripción sintáctica de WSDL indica cómo debe ejecutarse determinado servicio
web, pero no aclara qué es lo que está ejecutando. Si bien un humano puede interpretar
(en la mayoría de los casos), la semántica del servicio web, una máquina no puede
hacerlo. Para que el algoritmo de planning sea capaz de interpretar los servicios es
necesario definirlos en un lenguaje que les pueda proveer semántica a los mismos.
A un algoritmo de planning no le interesa el cómo, sino el qué. El algoritmo de planning
no es el encargado de realizar la ejecución de las acciones, por lo que no le interesan
las instrucciones internas para ejecutarla pero si conocer que hace.
Por otro lado, el algoritmo de planning debe decidir el orden con el que se debe ejecutar
las acciones para llegar a un objetivo a partir de un estado inicial. Para ello debe
comprender la semántica de las acciones y lo que conlleva cada una de ellas. Que hace
una acción, que necesito para ejecutarla, que efectos me produce, etc. Toda esta
información necesita ser descrita en un lenguaje entendible para la máquina, por lo que
WSDL no se considera un lenguaje suficiente en este contexto (V. Portchelvi et al.,
2012).
En cambio, WSMO y OWL-S son lenguajes que extienden el poder descriptivo de WSDL
permitiendo modelar estados del mundo, objetivos por los cuales un usuario debería
llamar cierto servicio web, las variables afectadas por la llamada del mismo,
precondiciones, postcondiciones, etc.5. Esta descripción semántica de los servicios web
5 https://www.w3.org/Submission/WSMO/
CAPITULO 3. ENFOQUE
23
contiene la información que un algoritmo de planning necesita para, dado un objetivo,
poder organizar las invocaciones a los servicios web.
Ambos lenguajes son adecuados para este proyecto en particular. Si bien WSMO utiliza
WSML (Web Service Modeling Language), el cual es más expresivo que OWL-S, OWL-
S corre con la ventaja de permitir describir procesos. Los servicios web están asociados
a procesos atómicos, los cuales tienen sus entradas, salidas, precondiciones, efectos,
y otros elementos semánticos. Además de todo esto, OWL-S permite describir procesos
compuestos por otros procesos. De esta forma se puede describir los planes creados
por los algoritmos de planning como nuevos procesos compuestos, enriqueciendo con
el tiempo el abanico de procesos y evitando de esta forma tener que planear dos veces
para un mismo objetivo.
Por todo lo anterior se optó finalmente por la utilización de OWL-S como lenguaje de
descripción de servicios web. En la siguiente sección se resaltan los detalles más
importantes y de interés para la tesis.
3.1.2 Definición de los servicios
En el capítulo 2 fueron explicados ciertos elementos de OWL-S. Estos elementos nos
sirven para describir los servicios que van a ser utilizados y posteriormente ejecutados.
Todo el detalle de la especificación semántica de los documentos OWL-S se encuentra
en el apéndice A.
Para entender mejor la descripción de los documentos y su posterior uso es necesario
definir un ejemplo conductor. En este caso particular utilizaremos un ejemplo que
consiste en un conjunto de servicios orientados a la obtención de datos climáticos a
partir de una ciudad en cuestión. Dentro del conjunto de servicios definidos podemos
encontrar los siguientes:
TemperatureCelcius(City): retorna la temperatura actual de la ciudad dada en
grados centígrados.
TemperatureFahrenheit(City): retorna la temperatura actual de la ciudad dada en
grados Fahrenheit.
FahrenheitToCelcius(TemperatureFahrenheit): convierte una temperatura de la
unidad de medida Fahrenheit a centígrados.
RainProbability(City): retorna la probabilidad de precipitaciones actual de la
ciudad dada.
Humidity(City): retorna el porcentaje de humedad actual de la ciudad dada.
WindMph(City): retorna la velocidad del viento en millas por hora.
MphToKph(WindMph): dada una unidad de medida en millas por hora la
convierte a kilómetros por hora.
CAPITULO 3. ENFOQUE
24
Forecast(City): retorna la temperatura en grados centígrados, la humedad, la
velocidad del viento en kilómetros por hora y la probabilidad de lluvia actual para
una ciudad dada.
Para definir dichos servicios en OWL-S en primera medida es necesario definir las
clases semánticas para cada uno de los tipos utilizados por los servicios. En nuestro
caso particular es necesario definir las siguientes clases:
City: representa una ciudad.
TemperatureCelcius: representación de una temperatura en grados centígrados.
TemperatureFahrenheit: representación de una temperatura en grados
Fahrenheit.
Rain: representa la probabilidad de lluvia.
Humidity: representa la humedad del ambiente.
WindMph: representa la velocidad del viento en millas por hora.
WindKph: representa la velocidad del viento en kilómetros por hora.
Estas clases estarán definidas dentro del archivo Ontology.owl de la siguiente manera:
Figura 3.2. Descripción de las clases en OWL-S.
Una vez definidas las clases podemos realizar la definición de los servicios dentro del
archivo Service.owl y su correspondiente perfil en el archivo Profile.owl. En estos
archivos se definirán los servicios y perfiles y se los agrupará dependiendo del perfil, es
decir, si más de un servicios pertenecen a un mismo endpoint se los podrá agrupar. A
continuación definiremos algunos de los servicios enumerados anteriormente y dos
CAPITULO 3. ENFOQUE
25
perfiles, uno privado y el otro público aunque solo se dará el ejemplo de la definición del
perfil privado.
Figura 3.3. Definición de los perfiles en OWL-S.
En la figura 3.3 se puede apreciar que el perfil privado consta de un solo servicio
denominado getForecast. Por otro lado, el perfil público contiene el resto de los
servicios. Más adelante se detalla el motivo y uso de cada uno de los perfiles.
Una vez definidos los servicios y su correspondiente perfil, será necesario definir el
proceso para cada uno de los servicios definidos anteriormente. Estos procesos deberán
ser definidos en el archivo Process.owl. y mapeados a los perfiles en el archivo
Grounding.owl. A continuación se define uno de los servicios más pequeños a modo de
ejemplo así como también el mapeo de algunos de los servicios y su correspondiente
grounding.
CAPITULO 3. ENFOQUE
26
Figura 3.4. Descripción de un proceso atómico o servicio en OWL-S.
Figura 3.5. Definición del grounding de los servicios en OWL-S.
CAPITULO 3. ENFOQUE
27
Figura 3.6. Descripción de los procesos para los servicios en OWL-S.
3.1.3 Representación de los documentos OWL
Todos los documentos inherentes a la descripción de los servicios web deben poder ser
interpretados y procesados para luego ser enviados al algoritmo de planning en
cuestión. Debido a esto será necesario realizar una aplicación que se encargue de
interpretar tanto los diferentes componentes de los archivos OWL como la conexión
entre ellos. Con lo cual para llevar a cabo esta tarea será necesario encontrar una
manera adecuada de modelar tanto los diferentes archivos OWL como el contenido de
los mismos.
Actualmente existe una gran variedad de lenguajes de descripción de servicios web y
de algoritmos de planning, con lo cual se creyó conveniente poseer una representación
intermedia abstracta de los servicios web. El objetivo de esta etapa intermedia consiste
en desvincular la representación inicial del servicio web del algoritmo de planning
utilizado posteriormente para la resolución del problema en cuestión.
3.1.4 Algoritmo de planeamiento
Cuando un usuario o una aplicación solicita la ejecución de un servicio web determinado,
por lo general el motivo radica en obtener nueva información del mundo o modificar el
estado del mismo. Por lo tanto, para poder traducir un servicio web a una acción en un
algoritmo de planning, el mundo del algoritmo necesitaría ser dinámico para poder
representar los cambios o la nueva información incorporada por el servicio web.
CAPITULO 3. ENFOQUE
28
En la literatura, existen trabajos (Guillermo Rodríguez et al., 2015) que utilizan
algoritmos de HTN (particularmente SHOP y SHOP2) para componer servicios web. Sin
embargo, estos trabajos no consideran las preferencias del usuario a la hora de realizar
una composición. El presente trabajo propone entonces la utilización de AG UCPOP
como algoritmo de planeamiento, ya que permite condicionar la composición de
servicios web mediante preferencias, restricciones y representaciones sobre el estado
del mundo. Así, en caso de que haya varias posibles composiciones para lograr un
mismo objetivo, se priorizará la composición que más se adecue a las preferencias del
usuario.
De todas maneras, la representación intermedia propuesta en la sección anterior nos
permite abstraernos tanto de la descripción de los servicios web como del algoritmo de
planning a utilizar. Esto nos permite poder realizar diferentes implementaciones para
cada uno de los diferentes algoritmos de planning existentes.
3.1.5 Interpretación de las preferencias
Como antes se mencionó, AG UCPOP permite la introducción de preferencias del
usuario. Las preferencias son restricciones en forma de expresiones lógicas (similares
a las restricciones de estado) que definen el orden de las acciones a considerar para el
plan actual en caso de que varias de estas acciones cumplan con los requisitos, es decir,
las preferencias valorizan una acción por sobre las demás. De esta forma si se tienen
varias acciones (en este caso particular las acciones toman forma de servicios web) que
cumplen el mismo objetivo, el algoritmo selecciona la que mayor preferencia tenga.
Las preferencias serán establecidas automáticamente en base a los atributos definidos
en los perfiles de los servicios. Esto servirá para establecer una preferencia inicial en
base a los atributos de los servicios web. Los atributos actualmente disponibles en el
archivo Profile.owl corresponden al costo del servicio y su disponibilidad.
El costo del servicio puede tomar dos valores posibles, con costo o sin costo. En caso
de no poseer costo tendremos un valor asociado de 1, en cambio, si el servicio posee
costo, el valor asociado a dicho parámetro será de -1.
La disponibilidad de un servicio estará comprendida por un valor entre 0 y 100. Este
valor representa el porcentaje de tiempo en el cual dicho servicio se encuentra
disponible para su uso. Esto quiere decir que cuanto mayor el valor, mayor es la
disponibilidad del servicio.
Finalmente el usuario podrá cambiar el valor de preferencia de cada uno de los servicios
desde la herramienta para configurar cada uno de los diferentes servicios de acuerdo a
sus intereses.
CAPITULO 3. ENFOQUE
29
3.2 PLANEAMIENTO
Luego de interpretar los diferentes documentos y las preferencias del usuario para cada
uno de los perfiles de servicios es necesario terminar de definir las otras entradas del
algoritmo y traducir todos estos datos de forma tal que pueda ser interpretado por el
algoritmo de planeamiento.
Para esto será necesario definir las restricciones, el dominio de los datos, el estado final,
transformar los servicios hacia acciones y a su vez traducir toda la información para
luego planear el conjunto de acciones y así generar un orden de ejecución que valide la
solución.
3.2.1 Definición de las preferencias
Las preferencias se escriben de la siguiente forma en AG UCPOP:
preference(Q,AC,AD,P,C) :- B
Q representa el objetivo que se busca cumplir cuando se selecciona la acción.
AC es la acción candidata a tener preferencia.
AD es la acción objetivo.
P es el peso de la preferencia, se mide con un valor entero. Mientras mayor es
el número mayor es la preferencia hacia esa acción.
C representa la confianza sobre la preferencia.
B es el cuerpo de la preferencia. Indica las condiciones que se deben cumplir
para que la preferencia sea válida.
Basándonos en los atributos definidos en la sección 3.1.5 la fórmula para calcular el
peso correspondiente a la preferencia de cada uno de los servicios será la siguiente:
Preferencia = D - (30 * C)
D corresponde al valor de la disponibilidad del servicio.
C se asocia al costo del servicio.
30 es el factor de corrección utilizado para ponderar el costo del servicio sobre
la disponibilidad del mismo. Este valor nos permite establecer un margen
máximo de prioridad en cuanto a la disponibilidad en caso de encontrar dos
servicios con el mismo valor de disponibilidad, pero con diferencias de costo.
CAPITULO 3. ENFOQUE
30
Siguiendo el ejemplo definido en la sección 3.1.1 donde el perfil del servicio posee una
disponibilidad de 95 y costo asociado, el valor de preferencia para este servicio será el
siguiente.
preference(_, Forecast(_,_,_,_,_), _, 65, 100)
Por el contrario, para un servicio sin costo (TemperatureCelsius) y con una
disponibilidad asociada de 70, la preferencia tomará la siguiente forma:
preference(_, TemperatureCelsius(_,_), _, 70, 100)
De ser necesario, la fórmula podrá ser ajustada en cada una de las diferentes
implementaciones de los algoritmos de planning durante la representación intermedia.
A su vez, los valores de preferencia resultantes podrán ser cambiados por el usuario
luego de haber sido calculada la preferencia base. Incluso, el usuario será capaz de
modificar y dar valor a las variables libres de los servicios para acotar el uso de las
preferencias, por ejemplo:
preference(_, TemperatureCelsius(tandil,_), _, 99, 100)
Con lo anterior estamos privilegiando el uso del servicio TemperatureCelisius
únicamente para la ciudad de Tandil. Esta preferencia se aplicará únicamente cuando
la primera variable del servicio sea “tandil”, de otra forma no se tendrá en cuenta.
3.2.2 Definición de las restricciones
AG UCPOP permite la definición de dos tipos posibles restricciones. Por un lado
tendremos las restricciones sobre las acciones que nos permite restringir el uso de cierta
acción en el plan. Estas restricciones tienen la siguiente forma:
constraintA (N,P,C,A) :- B
N es el nombre de la restricción y sólo cumple una función identificadora.
P es el peso de la restricción, se mide con un valor entero. Mientras mayor es el
número mayor es la restricción hacia esa acción.
C representa la confianza sobre la restricción.
A representa la acción sobre la cual se aplica la restricción.
B es el cuerpo de la restricción. Indica las condiciones que se deben cumplir
para que la restricción sea válida.
En segundo lugar se encuentran las restricciones sobre el plan. Este tipo de
restricciones permite restringir cierta combinación de acciones sobre el plan. Las
mismas tienen la siguiente forma:
CAPITULO 3. ENFOQUE
31
constraintP (N,P,C,P) :- B
N es el nombre de la restricción y sólo cumple una función identificadora.
P es el peso de la restricción, se mide con un valor entero. Mientras mayor es el
número mayor es la restricción hacia esa acción.
C representa la confianza sobre la restricción.
P representa el plan sobre el cual se realiza la restricción.
B es el cuerpo de la restricción. Indica las condiciones que se deben cumplir
para que la restricción sea válida.
Por otro lado, AG UCPOP define además el predicado actions(P, A) el cual instancia la
variable A con la lista de acciones pertenecientes al plan P. Esto permite utilizar Javalog
para realizar verificaciones sobre el plan y decidir la validez de la restricción.
3.2.3 Representación de los servicios
Con el diseño de la representación intermedia propuesta anteriormente en la sección
3.1.3 podremos implementar diferentes soluciones para la traducción desde los
lenguajes de descripción de servicios web (como OWL-S y WSMO) hacia esta
representación intermedia independientemente del algoritmo de planning que se desee
usar posteriormente. De la misma forma, se traducen los servicios de la etapa intermedia
a entradas para los distintos algoritmos de planning, independientemente del lenguaje
original con el cual se encontraba descrito el servicio. Esto sirve en gran medida para
obtener una mayor extensibilidad y reusabilidad en cualquiera de los casos descritos
anteriormente. El enfoque propuesto se puede apreciar en la figura 3.7.
Figura 3.7. Representación intermedia de los servicios interpretados.
Para lograr que la representación funcione, se necesita que la misma sea lo más
abarcativa posible para que no se pierda información de los servicios web durante su
traducción.
CAPITULO 3. ENFOQUE
32
3.2.4 Conversión de los servicios hacia el algoritmo de
planning
Cada servicio será representado por una acción. En el caso de AG-UCPOP, será
necesario definir los siguientes elementos para realizar la traducción hacia dichas
acciones:
Argumentos: Representa la lista de inputs de la acción.
Condiciones: Permiten definir condiciones directas sobre las variables (sin
instanciar las mismas) para que la acción sea aplicable, como equivalencias o
diferencias entre ellas.
Precondiciones: Permite definir las precondiciones necesarias en el plan para
poder agregar la acción al mismo.
Postcondiciones: Representan los efectos producidos por la acción.
Con lo cual las acciones se definirán de la siguiente forma:
action ( nombre_de_accion ( argumentos ),
[ condiciones ], [ precondiciones ], [ postcondiciones ]
). A modo de ejemplo, utilizando el servicio TemperatureCelcius definido en la sección
3.1.2, la traducción del mismo hacia una acción de AG-UCPOP nos quedaría de la
siguiente forma:
action ( TemperatureCelsius (V0, V1),
[], [city(V0)], [temperatureCelsius(V1)]
).
3.2.5 Generación del plan
Luego de interpretar y traducir todos los componentes antes mencionados se procede
a la generación del plan que posteriormente será interpretado por el algoritmo de
planning elegido, en nuestro caso AG UCPOP.
En primera medida necesitaremos definir el dominio del conjunto de los servicios. Para
esto hay que identificar, mapear y traducir las clases que son entrada y salida de cada
uno de los servicios. Posteriormente se definen y traducen las condiciones sobre las
clases antes interpretadas para darles un significado, y los efectos producidos por los
servicios. De esta forma se procederá a realizar la traducción de los servicios hacia
CAPITULO 3. ENFOQUE
33
acciones de AG UCPOP, los mismos poseerán variables de entradas, condiciones sobre
las variables y efectos. Como ejemplo podemos utilizar el servicio TemperatureCelsius
definido en la sección 3.1.2:
action ( TemperatureCelsius (V0, V1),
[], [city(V0)], [temperatureCelsius(V1)]
). V0 y V1 son variables de entrada y salida del servicio TemperatureCelsius, city(V0)
especifica una condición sobre la variable de entrada V0 a su vez definiéndola como
una clase, city. Por otro lado temperatureCelsius define el efecto temperatureCelsius
sobre la variable V1. Con lo cual podemos interpretar que la acción TemperatureCelsius
tiene como entrada una variable de tipo city y da como resultado una variable de tipo
temperatureCelsius.
Ahora tan solo falta agregar los estados, inicial y final, para poder realizar la ejecución
del plan.
3.2.6 Agregado del estado inicial y final
El estado inicial se define como un conjunto finito de variables que en la práctica deberán
tener un valor asociado. Por otro lado el estado final se define como un conjunto
particular de condiciones sobre las variables de salida.
A modo de ejemplo, teniendo el conjunto de servicios definidos en la sección 3.1.2
podremos definir los siguientes estados:
Estado inicial: City(Tandil)
Estado final: TemperatureCelsius(Tandil, T), WindMph(Tandil, W),
Humidity(Tandil, H)
Esto querrá decir que dada una ciudad(Tandil), queremos obtener la temperatura en
grados Celsius, el viento en millas por hora y la humedad de la misma. Pero para obtener
los valores de las variables T, W y H necesitamos ejecutar el plan en AG UCPOP para
obtener un resultado (plan de orden parcial) y de esa forma realizar la ejecución
ordenada de cada uno de los servicios incluidos en el resultado. En este caso particular
uno de los planes de orden parcial generados podría ser el siguiente:
CAPITULO 3. ENFOQUE
34
Figura 3.8. Plan de orden parcial.
Como se puede observar en la imagen anterior, las variables W, T y H fueron
reemplazadas por las variables aleatorias _0, _1 y _2 respectivamente. En cuanto al
orden de las acciones, en primer lugar será necesario ejecutar la acción que retorna una
temperatura en grados Fahrenheit para luego convertirla hacia grados Celsius, en
cambio las acciones que devuelven el viento y la humedad no poseen orden alguno, es
decir, pueden ser ejecutadas tanto antes como después de haber obtenido la
temperatura en grados Celsius.
Ahora tan solo falta mapear las acciones invocadas hacia los servicios previamente
definidos, y ejecutarlos en el orden dado para finalmente obtener los valores de las
variables.
3.3 EJECUCIÓN
Una vez que se posea un plan de orden parcial, el mismo deberá ser interpretado para
obtener los servicios que deben ser ejecutados. Posteriormente se ejecutarán dichos
servicios en el orden establecido para obtener el resultado final de la composición.
3.3.1 Interpretación del plan
Un plan de orden parcial se puede ver como un conjunto de acciones que deben ser
ejecutadas en orden. Dicho orden lo establecen los distintos niveles que forman parte
del mismo plan. El plan en cuestión puede tener más de una acción en el mismo nivel,
esto quiere decir que las acciones son totalmente independientes entre sí y pueden ser
ejecutadas de forma paralela. De forma contraria, las acciones que estén en distintos
CAPITULO 3. ENFOQUE
35
niveles son dependientes de alguna de las acciones que aparecen en los niveles
inferiores. A continuación se ejemplifican ambos casos.
Figura 3.9. Niveles de ejecución en el plan.
En la imagen anterior se puede ver el estado inicial, dos niveles de ejecución de
acciones y el resultado o estado final.
Las acciones windmph, temperatureFahrenheit y humidity se encuentran en el nivel 1,
esto quiere decir que las mismas pueden ser ejecutadas de forma paralela ya que no
son dependientes entre sí. En cambio la acción fahrenheitToCelsius se encuentra en el
nivel 2, esto significa que sus variables de entrada dependen directamente de las
variables de salida de algunas de las acciones del nivel 1, en este caso particular
depende del resultado de la acción temperatureFahrenheit.
Debido a que las acciones de un mismo nivel no tienen un orden particular entre las
mismas será conveniente transformar las acciones paralelas hacia una lista de acciones
para cada uno de los distintos niveles de forma tal que nos quede una lista ordenada de
servicios a ejecutar. Teniendo como referencia la figura 3.9, la conversión nos quedaría
de la siguiente forma:
CAPITULO 3. ENFOQUE
36
Figura 3.10. Transformación del plan parcial hacia una lista ordenada de acciones.
Una vez obtenida la lista ordenada de acciones podemos proceder a la interpretación y
ejecución del plan
Para poder interpretar el plan necesitaremos definir la transformación de las acciones
hacia servicios. En la figura 3.4 de la sección 3.1.2 se definió la entrada del servicio
getTemperatureCelsius como una city, y como salida retorna una TemperatureCelsius,
con lo cual cada servicio deberá poseer un conjunto de variables de entrada y otro
conjunto de salida.
Para los estados inicial y final se deberá definir un conjunto de variables. En el caso del
estado inicial las variables deberán estar instanciadas con sus respectivos valores
iniciales. En cambio para el estado final, se definirán las variables pero las mismas no
tendrán valor alguno ya que se espera que luego de haberse ejecutado la lista de
servicios todas las variables del estado final deben poseer valor, de lo contrario se
presupone que hubo un error durante alguna de las etapas previas.
CAPITULO 3. ENFOQUE
37
3.3.2 Ejecución del plan
Una vez interpretado el plan y luego de identificar las variables correspondientes a los
estados iniciales y finales se procederá a la invocación de los servicios con la finalidad
de instanciar las variables del estado final con sus correspondientes valores.
Para esto se deberá realizar una abstracción independientemente de los diferentes tipos
de servicios que existen ya que cada uno tendrá una manera distinta de realizar las
invocaciones. Luego simplemente se recorrerá la lista ordenada de servicios
ejecutándolos en orden y almacenando sus resultados temporales con el fin de
compartir las variables con los distintos servicios.
Finalmente, si todos los servicios fueron invocados exitosamente, y todas las variables
definidas por el estado final poseen valor, se podrá decir que encontramos una solución
a la composición.
3.4 Conclusión
En este capítulo se presentó un enfoque para la composición de servicios web que
permite la introducción de preferencias. Este enfoque propone la utilización del lenguaje
OWL para la descripción de los servicios web, la utilización de AG UcPop como
algoritmo de planeamiento y la manera de llevar a cabo la ejecución de la composición
de los servicios.
En el siguiente capítulo se expondrá el diseño e implementación de la aplicación basada
en este enfoque.
38
Capítulo 4
Diseño e implementación
Durante este capítulo se presenta la arquitectura de la herramienta propuesta para
realizar la interpretación, composición y ejecución de los servicios web utilizando
técnicas de planeamiento. La arquitectura se expone a través diferentes diagramas que
detallan las partes más relevantes de la misma. Los diagramas utilizados para explicar
la arquitectura son los siguientes:
Diagrama de paquetes: se utiliza para mostrar la agrupación lógica de los
componentes de la herramienta mostrando sus dependencias.
Diagrama de clases: representa una vista estática de la arquitectura en
donde se detallan las clases, atributos, métodos y relaciones entre clases que
conforman la herramienta.
Diagrama de secuencia: es utilizado para visualizar la interacción entre clases y
comprender como trabaja internamente la herramienta.
La primera sección del capítulo muestra una visión general de la arquitectura, detallando
los principales paquetes que componen la herramienta. Cada paquete es explicado en
detalle en las secciones siguientes mediante los diagramas de clases. A su vez en cada
sección se ilustran diagramas de secuencia que detallan el comportamiento de las
clases contenidas en el paquete.
El lenguaje elegido para el desarrollo de la aplicación fue Java debido a que durante la
carrera fue uno de los lenguajes más utilizados y con mayor potencial para desarrollar
la herramienta en cuestión. Esto permitió que los tiempos de desarrollo se reduzcan. A
su vez se utilizaron diferentes frameworks y aplicaciones que aceleraron la
implementación de la aplicación, por ejemplo la aplicación AG-UCPOP (Berdun et al.,
2011) encargada de interpretar los planes generados por nuestra herramienta y JDOM6
que permite leer documentos XML de manera más cómoda, rápida y eficiente.
6 http://www.jdom.org
CAPITULO 4. DISEÑO E IMPLEMENTACION
39
4.1 ARQUITECTURA GENERAL DE LA
HERRAMIENTA
Los componentes principales de la herramienta pueden ser visualizados en la figura 4.1.
El primer paquete que podemos observar es el Interpreter. El mismo se encarga de
interpretar y traducir los diferentes archivos OWL hacia la representación intermedia
descrita en la sección 3.2.3.
Luego, el paquete Converter utiliza los elementos generados por el Interpreter y se
encarga de realizar la transformación de todos los componentes hacia el lenguaje PDDL
usado por el algoritmo de planeamiento AG UCPOP.
Finalmente el paquete Executor se encarga de ejecutar los servicios para obtener el
resultado final. Para esto utiliza la salida generada por el algoritmo AG UCPOP en
conjunto con los servicios interpretados por el Interpreter.
Por otro lado se encuentra el paquete Utils. Este paquete contiene clases de utilidades
generales que facilitan las tareas de interpretación de los diferentes documentos OWL.
Figura 4.1. Diagrama de paquetes de la herramienta.
4.2 INTERPRETACIÓN Y MODELADO
La forma de describir los servicios en la ontología OWL, como cada uno de sus
diferentes componentes, es esencial para reducir la cantidad de acciones (y por
consiguiente los tiempos de ejecución del algoritmo de planeamiento a utilizar)
resultantes en la etapa de procesamiento y traducción hacia las acciones de AG
UCPOP. Por esto es necesario establecer una forma óptima de describir todos los
elementos necesarios en los diferentes archivos de descripción semántica OWL-S. Toda
esta información la podemos encontrar en el apéndice A.
CAPITULO 4. DISEÑO E IMPLEMENTACION
40
El paquete Interpreter está compuesto por un conjunto de subpaquetes creados para
separar las distintas funcionalidades presentes dentro del mismo, estos subpaquetes se
denominan Intermediate y Representation. Dichos subpaquetes contienen clases que
se encargan de interpretar y traducir los diferentes archivos OWL hacia una
representación intermedia con el fin de abstraer la representación de los documentos
de descripción de servicios del algoritmo de planning a utilizar. El conjunto de
subpaquetes se puede apreciar en la figura 4.2.
Figura 4.2. Diagrama de clases contenido en los subpaquetes del paquete Interpreter.
Por un lado tenemos al subpaquete Representation encargado de interpretar los
diferentes documentos OWL mientras que las clases contenidas en el subpaquete
Intermediate realizan la abstracción de la representación descrita anteriormente.
4.2.1 Representación intermedia, dominio de conjuntos
La manera de representar los diferentes documentos OWL en memoria es esencial para
todo el desarrollo de la herramienta. Por este motivo se decidió realizar la
implementación de una representación intermedia con la finalidad de abstraernos tanto
del algoritmo de planeamiento como de la representación de los diferentes servicios
web.
Para llevar a cabo dicha representación intermedia se decidió utilizar la teoría de
conjuntos. El concepto de conjunto es mucho más flexible que el concepto de clase ya
que permite que un elemento pertenezca a varios conjuntos al mismo tiempo sin
mayores problemas. Los conjuntos poseen nombre, engloban elementos y permiten
definir relaciones como uniones, intersecciones, disyunción y complementos, lo cual
facilita la tarea de plasmar en ella una ontología.
CAPITULO 4. DISEÑO E IMPLEMENTACION
41
Las relaciones entre elementos (que aparecen como propiedades de clases en OWL-S)
pueden verse como relaciones entre conjuntos. Si bien los conjuntos permiten
relaciones n-arias, cualquiera de ellas puede verse como múltiples relaciones binarias,
por lo cual se decide solo tener relaciones binarias en el diseño. Por ejemplo, si se tiene
definida la relación 4-naria Person entre Name, Last_Name, DNI y City de la siguiente
forma:
Person (Name, Last_Name, DNI, City)
Se puede ver a Person como un conjunto simple y se puede traducir a relaciones
binarias. Creando un elemento P como representación abstracta de una persona que
relacione todos elementos, se obtiene la siguiente representación:
Person (P) hasName (P, Name) hasLastName (P, Last_Name) hasDNI (P,DNI) hasCity (P,City)
El diseño de la representación intermedia del dominio se reflejó en la implementación
de seis clases pertenecientes al paquete Intermediate.Domain como se puede apreciar
en la figura 4.3:
CAPITULO 4. DISEÑO E IMPLEMENTACION
42
Figura 4.3. Conjunto de clases que definen la representación intermedia del dominio.
I. Predicate: La clase aparece como la abstracción entre los conjuntos y las
relaciones. Posee un nombre y un id único que lo representa.
II. Set: Esta clase representa los conjuntos, y hereda de la clase Predicate. Cada
conjunto puede estar definido como una unión de clases, una intersección de
clases, el complemento de otra clase o una lista bien definida de elementos
(representados por una clase Constant).
III. Relation: Esta clase representa las relaciones entre conjuntos, y hereda de la
clase Predicate. Cada relación posee referencias a los Set que relaciona,
propiedades lógicas (actualmente simetría y transitividad) y de cardinalidad
(actualmente inyectividad e inyectividad inversa).
IV. Axiom: Los axiomas indican relaciones de dominio entre dos predicados
(actualmente uniones, intersecciones, inclusiones e inversiones para el caso de
las relaciones entre conjuntos).
CAPITULO 4. DISEÑO E IMPLEMENTACION
43
V. Constant: Las constantes son elementos del dominio estáticos y ya conocidos.
Poseen un nombre y un id al igual que los predicados, pero no heredan de la
clase Predicate.
VI. Domain: El dominio representa la ontología completa. Posee el listado de
conjuntos y relaciones que conforman la ontología al igual que los axiomas que
los relacionan y las constantes conocidas. Cada uno de estos elementos es
identificado por una URI con el fin de evitar duplicados. Esta clase posee una
instancia estática denominada globalDomain, en la cual se almacenan todos los
elementos de todos los dominios generados en tiempo de ejecución. El objetivo
de la misma es tener todos los datos concentrados para evitar parsear e
interpretar dos veces un mismo elemento (ya que estos pueden estar definidos
en cualquiera de los archivos .owl), lo cual produciría el duplicado del mismo.
4.2.2 Diseño de los servicios web
Para representar los servicios web se considera cada servicio web como un conjunto de
características no funcionales y un conjunto de características funcionales. El conjunto
de características no funcionales consta de una representación simple y directa
(actualmente nombre del servicio, disponibilidad y costo). Por otra parte, la
representación de la parte funcional es un poco más compleja ya que necesita definir
las condiciones y efectos sobre las variables.
En el caso de la representación de las condiciones y los efectos se necesita modelar el
concepto de expresión. Una expresión consiste en un predicado instanciado con
argumentos, a su vez, los argumentos pueden representar variables o valores
constantes. El diseño de esta representación se encuentra alojado dentro del paquete
Intermediate.Expressions y se puede apreciar en la siguiente figura:
CAPITULO 4. DISEÑO E IMPLEMENTACION
44
Figura 4.4. Conjunto de clases que definen la representación de las condiciones funcionales.
I. Argument: Representa un argumento capaz de ser utilizado en una expresión.
Posee un id y establece métodos abstractos para la comparación de
argumentos.
II. Variable: Representa una variable y hereda de Argument. Implementa los
métodos para la comparación declarados como abstractos en la clase Argument.
III. Expression: Representa una expresión. Posee un predicado y un arreglo de
argumentos. Además posee un tipo que indica si es una expresión simple o
negada.
Por otro lado los servicios provistos son representados como acciones. Cada acción
posee las variables de entrada provistas por el cliente, las variables locales necesarias
para las precondiciones y las precondiciones necesarias. A su vez las acciones poseen
un conjunto de resultados alternativos. Cada uno de estos resultados indica los posibles
flujos de ejecución que puede tomar un servicio, y representan los resultados de estos
flujos, cada uno con sus salidas, efectos y condiciones bajo las cuales estos resultados
ocurren.
CAPITULO 4. DISEÑO E IMPLEMENTACION
45
El diseño de la representación intermedia de los servicios web se reflejó en la
implementación de tres nuevas clases en conjunto con las tres clases definidas
anteriormente y la clase Predicate perteneciente al dominio de conjuntos. Esta
funcionalidad se encuentra alojada en el paquete Intermediate.Service y su diagrama
de clases se puede apreciar en la siguiente figura:
Figura 4.5. Conjunto de clases que definen el diseño de los servicios web.
I. ActionResult: Representa el resultado alternativo de un servicio. Posee las
condiciones en las cuales ocurre así como los outputs y los efectos.
II. Action: Representa una funcionalidad del servicio ofrecido. Posee el nombre de
la funcionalidad, las entradas, las variables locales y las precondiciones del
servicio así como también los flujos alternativos del mismo, representados por
un vector ActionResult.
III. Service: Representa un conjunto de funcionalidades de un mismo proveedor.
Indica las características no funcionales y funcionales del mismo.
CAPITULO 4. DISEÑO E IMPLEMENTACION
46
4.2.3 Lectura e interpretación de las ontologías OWL
Se realizó una traducción conceptual desde las ontologías que permite describir OWL
hacia la representación intermedia planteada en el punto anterior. Si bien al final la
herramienta implementada es capaz de interpretar solo una pequeña parte de todas las
posibilidades que permite OWL, alcanza para demostrar los conceptos desarrollados en
el proyecto. Es solo una cuestión de tiempo e implementación expandir la solución hacia
todos los elementos definidos por OWL-S ya que los conceptos son sencillos de
comprender
Las clases OWL fueron interpretadas como conjuntos, los cuales pueden ser definidos
como enumeraciones, uniones, intersecciones, complementos o clases simples. Los
conjuntos pueden ser generados con nombre o anónimos, permitiendo crear estructuras
complejas en la que un conjunto con nombre está formado por alguna operación entre
varios conjuntos anónimos, abarcando así todas las posibilidades de clases descritas
por OWL.
Las propiedades de clases que permite definir OWL fueron interpretadas como
relaciones en la representación intermedias mientras que los individuales fueron
interpretados como constantes.
Los procesos atómicos fueron traducidos a Action. Las entradas, variables locales y
precondiciones de los procesos se trasladan a los mismos conceptos dentro de las
acciones. Los tipos de parámetros de las entradas y las variables locales se traducen a
precondiciones sobre las variables dentro de las acciones. Por su parte, los distintos
posibles resultados de un proceso son traducidos a ActionResult, a cuyas variables
también se traducen las salidas, las condiciones y los efectos del proceso
Para la interpretación de las ontologías descritas en OWL, se implementó la clase
OWLParser perteneciente al paquete Representation.OWL, la cual posee todas las
funciones necesarias para interpretar elementos OWL-S. Este parser es capaz de
interpretar clases, propiedades e individuales (Penberthy, J. S. and Weld, D) y realizar
una traducción de los mismos a la representación intermedia. Si bien la clase no posee
demasiada complejidad, resulta ser bastante extensa como se puede apreciar en la
figura 4.6 debido a la típica funcionalidad que identifica a los parsers.
CAPITULO 4. DISEÑO E IMPLEMENTACION
47
Figura 4.6. Clase OWLParser.
La clase posee los métodos getConstant y getPredicate los cuales a partir de una URI
devuelve el predicado o la constante descrito por el elemento OWL-S que posee esa
dirección. Además el método readFile recibe un archivo XML completo, permitiendo
traducir una ontología entera.
4.2.4 Lectura e interpretación de los documentos OWL-S
Debido a la complejidad de los archivos OWL-S fue necesario realizar la implementación
de un conjunto de clases que se encargan de interpretar dichos archivos con el fin de
obtener la información de los servicios descritos en ellos.
A continuación se da un pequeño resumen de la funcionalidad de las principales clases:
I. OWLSService: Se encarga de interpretar los servicios contenidos dentro del
archivo “Service.owl” y posteriormente invocar al Profile y al Gounding para
seguir generando la estructura.
II. OWLSServiceProfile: Se encarga de leer el contenido del archivo “Profile.owl”
para interpretar las condiciones de los servicios, es decir, el costo, disponibilidad
del mismo, etc.
III. OWLSGrounding: Esta clase se encarga de obtener los diferentes procesos
contenidos en el archivo “Grounding.owl” y realizar el mapeo hacia acciones de
la representación intermedia.
CAPITULO 4. DISEÑO E IMPLEMENTACION
48
El siguiente diagrama de clases muestra la forma en la cual se realizó la descomposición
de los archivos OWL-S.
Figura 4.7. Diagrama de clases correspondiente a la interpretación de los documentos OWL-S.
4.3 PLANEAMIENTO
Una vez obtenida la representación intermedia se procede a generar los archivos
necesarios para que los diferentes algoritmos de planning puedan realizar la ejecución.
En nuestro caso, la exportación fue realizada para funcionar únicamente con el algoritmo
AG UCPOP.
CAPITULO 4. DISEÑO E IMPLEMENTACION
49
4.3.1 Conversión hacia el algoritmo de planning
La traducción desde la representación intermedia hacia la entrada del algoritmo AG
UCPOP no fue sencilla. Esto se debe principalmente por las restricciones sobre el
mundo estático que plantea UCPOP contra el mundo abierto y desconocido de los
servicios web.
Como es de esperarse, cada acción de la representación intermedia fue traducida a una
acción de AG UCPOP. Sin embargo, AG UCPOP no permite resultados alternativos para
una misma acción. Este algoritmo de planeamiento es determinista, es decir, si yo tengo
permitido aplicar una acción, esta se va a poder ejecutar y sus efectos se cumplirán sin
excepción alguna. En cambio en el mundo de los servicios puede suceder que luego de
una invocación a un servicio este no responda, o bien que responda con error.
Para solucionar esta falta, cada acción intermedia fue traducida a varias acciones
UCPOP (una por cada resultado alternativo), en donde solo cambiaban los efectos de
cada una. Debido a que al momento de planear se desconocen las condiciones por las
cuales se va a generar un resultado u otro en el servidor, se optó por darle al algoritmo
todas las posibilidades y que este utilice la posibilidad que más le convenga.
4.3.2 Generación del plan
El principal problema de diseño que presenta la traducción hacia AG-UCPOP es el
hecho de no poder utilizar la capacidad del mismo para definir reglas en forma de
predicado. Esto impide indicarle al algoritmo restricciones de cardinalidad como por
ejemplo, cada persona puede tener solo un DNI asociado.
Este tipo de restricciones parecen triviales, pero si no se le indican al algoritmo, el mismo
puede dar resultados indeseables. En algunos casos de prueba donde en una ontología
de pronósticos de clima, se le pedía al algoritmo el pronóstico de dos ciudades, el
algoritmo lograba instanciar a un mismo pronóstico ambas ciudades, y el resultado era
inservible.
Como solución alternativa y como se aclaró anteriormente, AG UCPOP permite generar
restricciones sobre el plan. Estas restricciones permiten recorrer el conjunto de acciones
de plan mediante predicados. Conociendo los efectos de cada acción y los parámetros
sobre los cuales estos efectos ocurren, se pueden generar restricciones sobre el plan
que eviten el llamado de acciones con efectos conflictivos.
Supongamos tener una acción denominada getDNI que dada una persona retorna un
DNI asociado a la misma. Por contexto, se puede saber que llamar dos veces a esta
CAPITULO 4. DISEÑO E IMPLEMENTACION
50
acción con un mismo parámetro probablemente genere conflictos. Con lo que es buena
idea generar una restricción que no permita llamar dos veces a la acción getDNI con un
mismo parámetro. La misma se puede definir de la siguiente manera:
constraintP(restricciones_dominio, 10,100, Plan):-
acciones(Plan,Acc),
conflicto(Acc).
conflicto(Acc):-
hasDNI(Acc,Persona1),
hasDNI(Acc,Persona2),
Persona1 == Persona2.
hasDNI([action(getDNI(P),_)|Ls],P).
hasDNI([A|Ls],P) :- hasDNI(Ls,P).
Esto funciona correctamente en caso de que la relación sea funcional. El problema
persiste si la relación es inversamente funcional (como el caso del DNI). En este caso,
la invocación al método getDNI con dos personas distintas podría seguir produciendo
un problema si a ambas se le asigna el mismo DNI.
Para solucionar este problema se deben colocar las salidas de la acción como entradas,
y realizar la misma restricción anterior, considerando ahora también al DNI:
constraintP(restricciones_dominio, 10,100, Plan):-
acciones(Plan,Acc),
conflicto(Acc).
conflicto(Acc):-
hasDNI(Acc,Persona1,DNI1),
hasDNI(Acc,Persona2,DNI2),
( ( Persona1 == Persona2 , DNI1 \= DNI2) ;
( Persona1 \= Persona2 , DNI1 == DNI2) ).
hasDNI([action(getDNI(P,DNI),_)|Ls],P,DNI).
hasDNI([A|Ls],P,DNI) :- hasDNI(Ls,P,DNI).
Esta restricción permite evitar que una misma persona posea dos DNI o dos personas
posean el mismo DNI. A pesar del impacto en la performance debido a que este chequeo
se hace para cada iteración del algoritmo, es necesario realizar dicha comprobación
para evitar resultados que rompan con las reglas del dominio.
Como punto adicional, las violaciones de cardinalidad producidas por la definición del
estado inicial no pueden ser chequeadas. Una posible solución a este problema sería
describir el estado inicial como una acción sin precondiciones y con la lista de efectos
deseada para el estado inicial como postcondiciones, de forma tal que las restricciones
pudieran tener en cuenta estos efectos.
CAPITULO 4. DISEÑO E IMPLEMENTACION
51
4.3.3 Implementación de la traducción hacia el algoritmo de
planeamiento
El paquete denominado Converter se compone de cuatro clases las cuales se encargan
de realizar la traducción necesaria para que el algoritmo AG UCPOP pueda realizar la
interpretación de forma correcta. Estas clases se pueden apreciar en la siguiente figura:
Figura 4.8. Diagrama de clases correspondiente a la traducción hacia AG UCPOP.
I. UCPOPConverter: Es la clase maestra encargada de la conversación. La
misma recibe un Domain y una lista de Service de la representación intermedia
y genera todas las UCPOPAction, UCPOPRestriction y UCPOPPreference
correspondientes. A la hora de traducir simplemente traduce cada acción,
restricción y preferencia.
II. UCPOPAction: Dado un Action y un ActionResult genera la traducción
correspondiente a esa acción, traduciendo también los outputs de la acción a
inputs.
CAPITULO 4. DISEÑO E IMPLEMENTACION
52
III. UCPOPRestriction: Dada una Relation de la representación intermedia y un
conjunto de UCPOPAction, genera las restricciones necesarias sobre el plan
para que se cumplan las cardinalidades de esa relación en específico.
IV. UCPOPPreference: Dada una UCPOPAction y el Service a la cual pertenece,
se genera la preferencia de esa acción dependiendo de los valores contenidos
en las propiedades del Service y la preferencia introducida por el usuario en
cuanto al costo de los servicios.
Como anteriormente se especificó en la sección 3.2.1 del capítulo 3, las preferencias
son calculadas de acuerdo a los factores del costo y la disponibilidad del servicio. Esta
fórmula puede ser cambiada fácilmente en el método generate perteneciente a la clase
UCPOPPreference. A su vez, si se desean agregar más preferencias, las mismas
pueden ser agregadas directamente al algoritmo de planeamiento en cuestión.
Por otro lado, a una instancia de UCPOPConverter se le puede indicar un dominio
mediante el método setDomain. Una vez llamado este método, el UCPOPConverter
procede a leer los axiomas del dominio y la composición de los conjuntos con el fin
generar UCPOPAction por cada posible conversión existente (esto representa las reglas
de dominio). Luego se generan las UCPOPRestriction por cada relación del dominio con
restricciones de cardinalidad.
Cada vez que se agrega un servicio al UCPOPConverter con el método addService, se
generan todas las instancias de UCPOPAction y UCPOPPreference que corresponden.
En la siguiente figura se muestra un diagrama de secuencia de dicha funcionalidad:
CAPITULO 4. DISEÑO E IMPLEMENTACION
53
Figura 4.9. Diagrama de secuencia para la traducción hacia AG UCPOP.
Finalmente se realiza una traducción del problema completo. Para ello se traduce cada
acción, cada preferencia y cada restricción por separado. Las restricciones son los
únicos elementos cuya traducción depende de elementos externos (en este caso, del
listado de acciones que se está traduciendo).
4.4 EJECUCIÓN
Una vez generada la traducción de todos los elementos, es necesario establecer el
estado inicial y final para poder realizar la ejecución del algoritmo de planeamiento y, de
esta forma, obtener la composición de los servicios. Para llevar a cabo esta tarea
utilizamos la herramienta Ag-UCPOP (Berdun et al., 2011) la cual se encuentra basada
sobre el algoritmo de planeamiento UCPOP (Weld et al., 1992).
Para realizar el planeamiento, el usuario debe introducir dichos estados de la forma
descrita en la sección 3.2.6 en la herramienta provista para dar lugar a la ejecución del
algoritmo de planeamiento. A su vez, el usuario es capaz de modificar las preferencias
de los diferentes servicios si así lo desea, o incluso, eliminar los servicios que no desee
CAPITULO 4. DISEÑO E IMPLEMENTACION
54
tener en cuenta por el algoritmo de planeamiento. El resultado provisto por AG UCPOP
se compone de una lista ordenada de acciones denominada plan de orden parcial.
Luego de establecer los diferentes estados se procede a la ejecución del algoritmo de
planeamiento. El resultado del algoritmo deberá ser interpretado y posteriormente
ejecutado utilizando las variables definidas en el estado inicial para obtener el resultado
final de la composición. Este resultado estará compuesto por el conjunto de variables
definidas por el usuario en el estado final con su valor asociado. Si alguna de las
variables no llega a poseer valor, se afirma que alguno de los servicios no se encontraba
disponible al momento de la ejecución del servicio correspondiente, con lo cual el
resultado de la composición fallará.
4.4.1 Interpretación del plan
El plan de orden parcial generado por el algoritmo de planeamiento, en nuestro caso AG
UCPOP, se compone de las diferentes acciones que deben ser ejecutadas en un
determinado orden para obtener el resultado esperado. Como se introdujo en la sección
3.3.1, se debe transformar el grafo hacia una secuencia lineal de acciones. Esto nos
permite llevar a cabo la ejecución de los diferentes servicios web de manera lineal. El
siguiente pseudocódigo muestra los pasos a seguir para realizar la transformación del
grafo hacia una secuencia lineal de acciones.
Luego de obtener la secuencia lineal de acciones a ejecutar es necesario interpretarla.
Para llevar a cabo esta tarea se define el conjunto de clases definido en la figura 4.10.
CAPITULO 4. DISEÑO E IMPLEMENTACION
55
Figura 4.10. Diagrama de clases correspondiente a la interpretación del plan de orden parcial.
Como se pudo observar en la figura 4.10 se utilizó un patrón de diseño denominado
Composite. Este patrón de diseño sirve para construir objetos complejos a partir de otros
más simples y similares entre sí, gracias a la composición recursiva. La implementación
del patrón se debe a que una acción puede ser considerada también como un plan
debido a que la misma posee un conjunto de variables de entrada y que a su vez puede
ser ejecutada para obtener un resultado. En resumen, una acción es un plan que
únicamente posee una acción.
I. AbstractPlan: Clase abstracta que contiene la estructura y el comportamiento
que posee un plan de orden parcial. El mismo posee un estado inicial y puede
ser ejecutado mediante el método execute para obtener el resultado del plan.
II. Action: Representa una acción de AG UCPOP. La misma posee un nombre, un
servicio web asociado y hereda de AbstractPlan las propiedades del estado
inicial y final. El método execute invoca al servicio asociado para obtener el
resultado del mismo. A su vez el estado inicial posee un orden determinado por
la lista paramsOrder.
III. Plan: Clase que hereda todas las propiedades y el comportamiento de la clase
abstracta AbstractPlan. En este caso, el comportamiento del método execute
simplemente recorrerá la lista de AbstractPlan ejecutando cada una de las
instancias.
CAPITULO 4. DISEÑO E IMPLEMENTACION
56
4.4.2 Representación de los servicios
Debido a que hoy en día existen diferentes representaciones de servicios web, como
por ejemplo WSDL y REST, se decidió crear una interfaz que nos provea de los métodos
necesarios para llevar a cabo la ejecución de cualquier tipo de servicio. Por lo tanto,
deberemos utilizar esta interfaz para crear los tipos de servicios que deseen ser
ejecutados. La misma se denomina ServiceInterface.
En nuestro caso, se llevó a cabo la implementación de la clase RestService. Esta clase
implementa el método execute provisto por la interfaz ServiceInterface la cual permite
invocar servicios web del tipo REST. En la figura 4.11 se puede apreciar el diagrama de
clases correspondiente a la interfaz ServiceInterface en conjunto con la implementación
de la clase RestService que a su vez posee un Service proveniente del paquete
Interpreter.Intermediate.Service que posee todos los elementos necesarios para llevar
a cabo la invocación del mismo.
Figura 4.11. Diagrama de clases correspondiente a la representación de los servicios.
CAPITULO 4. DISEÑO E IMPLEMENTACION
57
4.4.3 Ejecución del plan generado
Luego de interpretar el plan de orden parcial y transformar el mismo hacia la lista
ordenada de acciones perteneciente a la clase Plan, podremos empezar a ejecutar los
servicios. Esta tarea no conlleva dificultad alguna, simplemente se llevara a cabo la
invocación del método execute perteneciente al Plan. Este método ejecutará de forma
secuencial cada uno de los diferentes Service con el fin de ir instanciando las diferentes
propiedades definidas en el finalState incluido en el Plan.
Terminada la invocación de los servicios procederemos a validar la solución. Para esto,
se comprobará que todos los elementos definidos en el finalState posean valor, ya que
si alguna de estas no posee valor podemos asegurar que alguno de los servicios pudo
ser invocado pero su resultado no fue obtenido. De la misma forma, si alguno de los
servicios falla durante su ejecución, se cortara la ejecución de los servicios restantes y
se retornará un error al usuario. Esto se debe a que el resultado de los servicios
posteriores dependen directamente del resultado del servicio invocado. Este
comportamiento se puede apreciar en el diagrama de secuencia de la figura 4.12.
Figura 4.12. Diagrama de secuencia correspondiente a la invocación de los servicios.
CAPITULO 4. DISEÑO E IMPLEMENTACION
58
4.5 Conclusión
Durante el desarrollo de este capítulo se pudo apreciar en detalle la implementación
llevada a cabo para satisfacer el diseño propuesto en el capítulo 3. La utilización de
interfaces y clases abstractas en conjunto con la representación intermedia propuesta
nos permite desacoplar cada uno de los componentes utilizados (lenguaje de
descripción de los servicios, algoritmo de planeamiento y representación de los
servicios) para ajustar la solución de acuerdo a nuestras necesidades.
59
Capítulo 5
Resultados experimentales
Durante el desarrollo de este capítulo se presenta una serie de experimentos que
permiten evaluar diferentes aspectos de la composición inteligente de servicios. El
objetivo de esta evaluación es medir el impacto que generan las preferencias
establecidas por el usuario para la composición y ejecución de servicios web, en el
resultado final.
En primer lugar, se especifica el modo en el cual se lleva a cabo la composición de los
servicios utilizando la herramienta desarrollada. Para llevar a cabo esta tarea, se detalla
el uso de la herramienta mediante un ejemplo conductor, que nos permite ver el
funcionamiento general de la misma. Este ejemplo corresponde a una continuación del
caso utilizado como conductor a lo largo del capítulo 3.
En segundo lugar, se plantean diferentes escenarios de uso de la herramienta, tanto
con la utilización de preferencias por parte del usuario como sin la utilización de las
mismas. De esta manera, podremos evaluar el impacto que genera el uso de
preferencias introducidas por el usuario en los planes generados por la herramienta.
Para obtener el impacto que tiene el uso de preferencias, se evaluaran dos casos de
estudio. El primero de ellos consta de un conjunto de servicios que permiten obtener
distintos parámetros del clima de una ciudad en particular mientras que el segundo
consta de un conjunto de servicios que permiten obtener datos de vuelos, hospedajes,
tours y transportes necesarios para realizar un viaje. Este último caso de estudio es
analizado en varios trabajos, como el de D. Barreiro et al., y P. Stelmach 2013.
5.1 Definición de los casos de estudio
CAPITULO 5. RESULTADOS EXPERIMENTALES
60
El primer caso de estudio consta de un conjunto de servicios que permiten obtener
diferentes datos climáticos de una ciudad específica, como también realizar la
conversión entre diferentes unidades de medida. En la tabla 5.1 presentada a
continuación se define el conjunto de servicios con sus respectivos parámetros de
entrada (entradas), sus valores de retorno (salidas), su disponibilidad (D) y si posee
costo asociado o no (C):
Nombre del servicio Entradas Salidas D C
CityForecast CityZip TemperatureCelsius, WindKph, RainProbability, Humidity
95 Si
Pressure CityZip Pressure 75 Si
TemperatureCelsius CityName TemperatureCelsius 75 No
TemperatureKelvin CityName TemperatureKelvin 75 No
TemperatureFahrenheit CityName TemperatureFahrenheit 75 No
WindMph CityName WindMph 75 No
WindKph CityName WindKph 75 No
RainProbability CityName RainProbability 75 No
Humidity CityName Humidity 75 No
FahrenheitToCelsius TemperatureFahrenheit TemperatureCelsius 75 No
FahrenheitToKelvin TemperatureFahrenheit TemperatureKelvin 75 No
KelvinToFahrenheit TemperatureKelvin TemperatureFahrenheit 75 No
KelvinToCelsius TemperatureKelvin TemperatureCelsius 75 No
CelsiusToKelvin TemperatureCelsius TemperatureKelvin 75 No
CelsiusToFahrenheit TemperatureCelsius TemperatureFahrenheit 75 No
CityNameToCityZip CityName CityZip 75 No
CityZipToCityName CityZip CityName 75 No
WindKphToMph WindKph WindMph 75 No
WindMphToKph WindMph WindKph 75 No
Tabla 5.1. Descripción de los servicios en el caso de estudio de los servicios del clima de una ciudad.
El segundo caso de estudio se encuentra compuesto de servicios que permiten obtener
información de las diferentes etapas que forman parte de un viaje, como pueden ser:
CAPITULO 5. RESULTADOS EXPERIMENTALES
61
vuelos, hospedaje, servicios de transporte y diferentes excursiones que se puedan llevar
a cabo en la ciudad de destino. En la tabla 5.3 se detalla el conjunto de servicios
presente en este caso de estudio.
Nombre del servicio
Entradas Salidas D C
BookTravel Date, Date, CityName
Hotel, Flight, Transport, Tours
99 Si
BookHotel Date, Date, CityZip Hotel 65 No
BookFlight Date, Date, CityZip Flight 65 No
BookTransport Date, Date, CityZip Transport 65 No
BookTours Date, Date, CityZip Tours 65 No
CityNameToCityZip CityName CityZip 80 No
CityZipToCityName CityZip CityName 80 No
Tabla 5.2. Descripción de los servicios en el caso de estudio correspondiente a los servicios de viajes.
Las entradas y salidas expuestas anteriormente para ambas ontologías corresponden a
las representaciones definidas en tabla 5.3.
Parámetro Representación
TemperatureCelsius Temperatura en grados centígrados
TemperatureKelvin Temperatura en grados kelvin
TemperatureFahrenheit Temperatura en grados Fahrenheit
Pressure Presión atmosférica
WindMph Velocidad del viento en millas por hora
WindKph Velocidad del viento en kilómetros por hora
RainProbability Probabilidad de precipitaciones
Humidity Porcentaje de humedad
CityName Nombre de una ciudad
CityZip Código postal de una ciudad
Hotel Hotel
Flight Vuelo
Transport Transporte
CAPITULO 5. RESULTADOS EXPERIMENTALES
62
Tour Atracción turística
Tabla 5.3. Representación de las variables utilizadas por los servicios de las tablas 5.1 y 5.2.
5.2 Utilización de la herramienta
Para ejemplificar la utilización de la herramienta se utiliza el caso de estudio
correspondiente a los servicios del clima. En primera medida se necesita especificar la
ontología para el conjunto de servicios que componen el caso de estudio. Para esto, es
necesario definir las clases y propiedades en el archivo Ontology.owl. Seguidamente,
se define la funcionalidad de los servicios en el archivo Process.owl para luego vincular
cada proceso con su correspondiente servicio en el archivo Grounding.owl. Por último,
se definen los perfiles de los servicios en el archivo Profile.owl para finalmente vincular
los perfiles a cada grounding en el archivo Service.owl. La forma de definir la ontología
es similar a lo visto en la sección 3.1.2. En caso de dudas a la hora de llevar a cabo la
definición de la ontología se puede consultar el apéndice A.
Luego de definir la ontología será necesario abrir la herramienta para poder cargarla.
Figura 5.1. Pantalla inicial de la herramienta con el menú desplegado.
CAPITULO 5. RESULTADOS EXPERIMENTALES
63
En la figura 5.1 se puede apreciar las dos maneras existentes de cargar los archivos
que provee la interfaz de la herramienta, así como también los diferentes componentes
de la interfaz que permiten cambiar los valores de las preferencias, realizar la traducción
hacia AG UCPOP y ejecutar la composición de los servicios.
Una vez cargada la ontología, podemos ver que todos los servicios pertenecientes a la
misma se encuentran bajo la sección Services. La sección Properties y Output muestran
la información referente a cada servicio. Para ver esta información es necesario realizar
doble click sobre alguno de los servicios que se muestran en la sección izquierda. Bajo
la sección Properties se pueden ver los atributos del servicio así como la preferencia
base calculada por la herramienta. En tanto que la sección Output muestra la
información del proceso definida en la ontología, así como sus entradas, condiciones
sobre las entradas, salidas, condiciones sobre las salidas, precondiciones y efectos.
Figura 5.2. Interfaz de la herramienta luego de cargar la ontología y hacer click sobre un servicio.
Por otro lado, la preferencia del servicio puede ser cambiada por el usuario. Este valor
deberá estar comprendido entre -100 y 100. A mayor valor, mayor será la preferencia
sobre el servicio en cuestión. Para esto, se debe seleccionar un servicio y luego
modificar el valor de acuerdo con la preferencia que se desee. Los valores finales de las
preferencias se verán reflejados luego de convertir los servicios hacia AG UCPOP.
El paso siguiente será introducir el estado inicial y final para generar la traducción hacia
AG UCPOP mediante la utilización del botón Convert. En la figura 5.3 presentada a
CAPITULO 5. RESULTADOS EXPERIMENTALES
64
continuación se puede apreciar que la sección Output es ahora editable, esto nos
permite definir nuevas preferencias o incluso cambiar las variables libres para que solo
sean aplicable a ciertos parámetros.
Figura 5.3. Traducción hacia AG UCPOP.
En la figura anterior se puede ver el resultado de la traducción luego de modificar la
preferencia del servicio TemperatureCelsius a 90 únicamente para la ciudad de Tandil,
introducir el estado inicial, el estado final, y generar la traducción hacia AG UCPOP.
Una vez generada la traducción hacia el algoritmo de planeamiento se procede a realizar
la ejecución del mismo para obtener la composición de los servicios. El botón Execute
nos permite realizar la invocación del algoritmo de planeamiento y ejecutar los servicios
para obtener el resultado final de la composición.
En la figura 5.4 se puede apreciar la solución otorgada por AG UCPOP. Esta solución
se compone de los servicios TemperatureCelsius y CelsiusToKelvin. Esto se debe a que
el valor de preferencia del servicio TemperatureCelsius se encuentra por encima del
resto de los servicios que permiten obtener la temperatura para la ciudad de Tandil.
Debido a esto, el algoritmo de planeamiento utilizará en primera medida el servicio
TemperatureCelsius y luego invocará al servicio CelsiusToKelvin para realizar la
conversión desde grados kelvin a grados centígrados.
CAPITULO 5. RESULTADOS EXPERIMENTALES
65
Figura 5.4. Solución otorgada por AG UCPOP.
El resultado de la composición se puede apreciar bajo la sección Output. En la figura
5.5 se puede apreciar el resultado final de la composición de los servicios.
Figura 5.5. Invocación de los servicios.
El resultado final obtenido es, como se había pedido en el estado final, una temperatura
en grados kelvin para la ciudad introducida en el estado inicial. Este resultado se pudo
obtener luego de realizar la invocación de los servicios TemperarureCelsius y
CelsiusToKelvin utilizando la ciudad de Tandil como parámetro de entrada.
CAPITULO 5. RESULTADOS EXPERIMENTALES
66
5.3 Pruebas realizadas
A continuación se detalla cada una de las pruebas realizadas para los diferentes casos
de estudio así como los resultados obtenidos.
5.3.1 Caso de estudio: servicios de clima
Para este caso de estudio se realizaron dos pruebas diferentes, utilizando preferencias
y sin la utilización de las mismas. La meta se basa en obtener todos los datos del clima
para la ciudad de Tandil y Olavarría. Los datos del clima que se desean obtener son los
siguientes:
I. Temperatura expresada en grados centígrados.
II. Velocidad del viento en kilómetros por hora.
III. Probabilidad de precipitaciones.
IV. Porcentaje de la humedad en el ambiente.
V. Presión atmosférica.
Con lo cual los estados inicial y final se definen de la siguiente manera:
Estado inicial: cityname(olavarria),
cityzip(7000)
Estado final: temperaturekelvin(TO),
hastemperature(O, TO),
windmph(WO),
haswind(O, WO),
rainprobability(RO),
hasrainprobability(O, RO),
humidity(HO),
hashumidity(O, HO),
pressure(PO),
haspressure(O, PO),
temperaturecelsius(TT),
hastemperature(T, TT),
windkph(WT),
haswind(T, WT),
rainprobability(RT),
hasrainprobability(T, RT),
humidity(HT),
hashumidity(T, HT),
pressure(PT),
haspressure(T, PT)
CAPITULO 5. RESULTADOS EXPERIMENTALES
67
5.3.1.1 Primera prueba
Para la primera de las dos pruebas se modificó la preferencia de los servicios con costo
a 75. De esta forma, no se privilegia el uso de ninguno de los servicios contenidos en el
conjunto de prueba.
La solución provista se compone por siete servicios y se puede apreciar en la figura 5.6.
Si bien todos los servicios poseen la misma preferencia, podemos apreciar que dentro
del conjunto de servicios a invocar se encuentran dos servicios con costo, CityForecast
y Pressure. Esto se debe a que durante la definición de la ontología, el servicio
CityForecast se encuentra declarado antes que el resto de los servicios que proveen el
mismo resultado, con lo cual el algoritmo de planeamiento lo utiliza en primer lugar. Por
lo tanto, se puede afirmar que el orden de los servicios establecido durante su definición
modifica los planes generados por el algoritmo de planeamiento cuando no existe
preferencia sobre los servicios que aportan la misma solución.
Figura 5.6. Solución para la primera prueba de servicios del clima.
CAPITULO 5. RESULTADOS EXPERIMENTALES
68
5.3.1.2 Segunda prueba
En cambio, para la segunda de las pruebas, se modificó la preferencia sobre los
servicios con costo (Pressure y CityForecast) estableciendo la misma en 50. De esta
forma se privilegia los servicios gratuitos que permiten obtener los diferentes datos del
clima así como las transformaciones de unidades; en segundo lugar tendremos los
servicios con costo asociado.
El resultado de esta prueba se puede apreciar en la figura 5.7. La solución se encuentra
compuesta en gran medida por servicios sin costo, a excepción del servicio Pressure.
Esto se debe a que no existe un servicio sin costo que calcule la presión atmosférica de
una ciudad.
Figura 5.7. Solución para la segunda prueba de servicios del clima.
5.3.1.3 Tercera prueba
Finalmente, para la última prueba se utilizaron las preferencias de la prueba 2, a
excepción de los siguientes servicios:
CAPITULO 5. RESULTADOS EXPERIMENTALES
69
preference(_, TemperatureCelsius(_,_), _, 95, 100)
preference(_, TemperatureFahrenheit(olavarria,_), _, 99, 100)
preference(_, WindMph(_,_), _, 90, 100)
Como se puede apreciar en la figura 5.8, los 3 servicios mencionados anteriormente
fueron utilizados. El servicio TemperatureFahrenheit, a pesar de poseer un valor de
preferencia de 99, fue únicamente utilizado para la variable de entrada “olavarria”,
mientras que para el código postal 7000 el servicio utilizado fue TemperatureCelsius.
En cuanto al servicio WindMph, el mismo fue utilizado tanto para la ciudad “olavarria”
como para el código postal 7000 debido a que no se especificó ningún valor en las
variables de entrada de dicho servicio.
Figura 5.8. Solución para la tercera prueba de servicios del clima.
CAPITULO 5. RESULTADOS EXPERIMENTALES
70
5.3.1.4 Resultados
La primera de las pruebas se llevó a cabo sin la utilización de preferencias para poder
comparar el resultado con el resto de las pruebas que poseen preferencias definidas por
el usuario. En la tabla 5.4 presentada a continuación se puede apreciar los resultados
de las pruebas realizadas y, a su vez, comparar el valor total de las preferencias
cumplidas cuando se toman en cuenta las preferencias del usuario.
Ejecución sin preferencias Ejecución con preferencias
Segunda prueba 225 675
Tercer prueba 225 1109
Tabla 5.4. Resultados de las pruebas correspondiente al primer caso de estudio.
En la tabla anterior se puede ver que los resultados obtenidos cuando se utilizaron
preferencias del usuario incrementaron los valores de preferencia en el resultado
otorgado por la herramienta. Por otro lado en las figuras 5.6, 5.7 y 5.8 se puede apreciar
como varía la solución en función de las preferencias definidas por el usuario.
5.3.2 Caso de estudio: servicios de viaje
Para este caso de estudio se llevaron a cabo tres pruebas que involucran tanto la
utilización de preferencias como la ausencia de las mismas. En todos ellos se desea
obtener toda la información necesaria para llevar a cabo un viaje hacia Londres, es decir,
obtener los vuelos, hotel, transporte y excursiones en el destino.
5.3.2.1 Primera prueba
En la primera prueba se llevó a cabo la eliminación de todas las preferencias
previamente calculadas por la herramienta. Esto dio lugar a que la solución obtenida se
componga únicamente por el servicio BookTravel debido al orden en el cual se
encuentran definidos los servicios en la ontología.
5.3.2.2 Segunda prueba
Para la segunda prueba se utilizaron las preferencias calculadas por la herramienta
salvo por los servicios BookHotel al cual se le modificó la preferencia para que tenga un
valor de 99, y el servicio BookFlight el cual poseerá un valor de preferencia de 80. Por
lo tanto, los valores de preferencia para cada uno de los servicios son los siguientes:
CAPITULO 5. RESULTADOS EXPERIMENTALES
71
BookHotel: 99
BookTransport: 65
BookTour: 65
BookFlight: 80
BookTravel: 69
CityNameToCityZip: 80
CityZipToCityName: 80
En este caso, la solución obtenida se compone por los servicios que poseen un mayor
valor de preferencia. Si bien la solución se podría haber realizado invocando tan solo al
servicio BookTravel, los valores de preferencia definidos para esta prueba hacen que
se incluyan los servicios BookHotel, BookFlight y CityNameToCityZip. Esto puede
parecer un factor en contra debido a que es necesario ejecutar el servicio BookTravel
para obtener los datos del transporte y los tours, siendo que el mismo servicio nos
provee de todos los datos necesarios.
5.3.2.3 Tercera prueba
Para llevar a cabo la tercera prueba se modificaron las preferencias otorgadas por la
herramienta para privilegiar la utilización de servicios sin costo. Para esto se disminuyó
la preferencia del servicio BookTravel a 0.
El resultado hallado en este caso se compone de los cuatro servicios gratuitos que nos
permiten obtener los diferentes datos del viaje en conjunto con el servicio que permite
realizar la transformación del nombre de la ciudad hacia el código postal de la misma
(necesario para los demás servicios incluidos en la solución).
5.3.2.4 Resultados
De la misma forma que en la sección 5.3.1.4, a continuación podemos apreciar una tabla
comparativa que nos permite visualizar los resultados de las pruebas realizadas.
Ejecución sin preferencias Ejecución con preferencias
Segunda prueba 69 458
Tercera prueba 69 340
Tabla 5.5. Resultados de las pruebas correspondiente al segundo caso de estudio.
En la tabla 5.5 se puede apreciar que la utilización de preferencias modificó los
resultados otorgados por la herramienta así como también el valor total de preferencias
CAPITULO 5. RESULTADOS EXPERIMENTALES
72
cumplidas. Los resultados arrojados por la herramienta cuando se utilizan preferencias
son más acordes a los deseados por el usuario.
5.4 Conclusión
Los resultados de las pruebas realizadas muestran que la utilización de preferencias
logra obtener soluciones más acorde con los requisitos del usuario. Debido a como
están compuestos los data sets y la preferencia por utilizar servicios sin costo, la
cantidad de servicios necesarios para obtener una solución puede incrementarse. Esto
tiene un problema particular, a mayor cantidad de servicios, mayor es la probabilidad de
que alguno de estos falle durante la ejecución. Con lo cual, el usuario debe tener en
cuenta tanto la disponibilidad de los servicios como la preferencia definida para evitar
posibles problemas durante la ejecución de la solución.
73
Capítulo 6
Conclusiones
Durante esta tesis se llevó a cabo el desarrollo de una herramienta capaz de interpretar,
planear, componer y llevar a cabo la invocación de servicios web de manera automática.
Esta herramienta permite desacoplar los diferentes componentes de la misma (lenguaje
de descripción de servicios, algoritmo de planeamiento y ejecución de servicios)
mediante un conjunto de interfaces, clases abstractas y una representación intermedia
encargada de interpretar y traducir los diferentes servicios existentes.
A su vez, la herramienta permite la introducción de preferencias por parte del usuario,
permitiendo privilegiar la utilización de algunos servicios sobre otros. Las preferencias
pueden ser definidas de dos formas distintas. La primera de estas se realiza es a través
de los atributos de los servicios definidos en la ontología (costo y disponibilidad). En este
caso la herramienta calculará de manera automática un valor de preferencia teniendo
en cuenta los valores de los atributos. La segunda consiste en definir un valor de
preferencia para cada servicio desde la interfaz del usuario, permitiendo a éste
privilegiar los servicios requeridos a su manera.
Las preferencias asociadas a cada servicio son tenidas en cuenta durante la ejecución
del algoritmo de planeamiento. El mismo, ordena la lista de servicios disponibles
considerando en primer lugar los servicios con mayor valor de preferencia. Luego,
recorre la lista en forma ordenada, comenzando por los mayores valores de preferencia,
comprobando por cada servicio, si la inclusión de éste en la solución parcial puede
conducir a la solución establecida por el usuario.
Finalmente, la herramienta fue puesta a prueba en dos casos de estudio. Para ambos
casos se llevaron a cabo diferentes pruebas que incluyen tanto la inclusión de
preferencias como la omisión de las mismas. Los resultados obtenidos por la
herramienta cuando se utilizaron preferencias del usuario mejoraron sustancialmente
los planes generados, haciendo que las soluciones obtenidas incluyan un número mayor
de servicios privilegiados por el usuario.
CAPITULO 6. CONCLUSIONES
74
En ambos casos se pudo comprobar que la utilización de un algoritmo de planeamiento
que soporte la introducción de preferencias por parte del usuario, permite obtener un
resultado más acorde a los requisitos del usuario. Sin embargo, los resultados obtenidos
en las pruebas demuestran que en algunos casos el número de servicios puede
incrementarse dependiendo de las preferencias del usuario.
6.1 Limitaciones y trabajos futuros
Si bien la herramienta ha demostrado ser capaz de generar resultados más acorde a las
preferencias del usuario, la misma posee las siguientes limitaciones. La primera de ellas
tiene que ver con la forma en la que se genera la ontología de los servicios. Actualmente
es necesario transcribir esta ontología de forma manual partiendo de las definiciones de
los servicios WSDL, REST, etc. A futuro, se podría llevar a cabo la realización de una
herramienta capaz de transcribir los diferentes lenguajes de descripción de servicios
hacia OWL de manera automática, facilitando de esta manera la creación de la
ontología.
En segundo lugar, el lenguaje utilizado para definir el estado inicial y final debe poseer
la misma sintaxis que el utilizado por el algoritmo de planeamiento. Para solucionar este
inconveniente se podría llegar a desarrollar un componente que permita al usuario
definir los estados utilizando el lenguaje natural para, posteriormente, realizar la
traducción hacia cada uno de los algoritmos de planeamiento incluidos en la
herramienta.
75
Apéndice A
OWL en detalle
OWL posee una gran variedad de elementos sintácticos que nos permiten definir
diferentes propiedades semánticas. Todas estas propiedades pueden encontrarse en
su documentación oficial7. A continuación se presenta un análisis de la sintaxis,
semántica y los aspectos más importantes de OWL-S que fueron utilizados en esta tesis.
A.1 Sintaxis
La sintaxis de OWL-S es muy amplia y permite la definición de muchos elementos. Por
esto mismo a continuación se detallarán algunos de los elementos que fueron
considerados y utilizados para las definiciones de los servicios durante el desarrollo de
la tesis.
A.1.1 Clases
OWL permite definir clases identificables (con nombre) para ser utilizadas como
entidades. Por ejemplo, se puede definir la clase Person de la siguiente manera:
<owl:Class rdf:ID="Person"> </owl:Class>
Lo anterior define la clase simple Person, pero no dice nada más acerca de la misma.
En OWL se pueden dar detalles sobre una clase definiendo detalles de la misma o
relacionándola con otras clases mediante el uso de axiomas.
7 https://www.w3.org/Submission/OWL-S/.
APENDICE A. OWL EN DETALLE
76
A.1.2 Axiomas de clases
Los axiomas de clases indican relaciones entre un par de clases. Existen tres tipos de
axiomas:
SubClassOf: Este axioma indica herencia. Cuando la clase A es una subclase
de B, todo elemento de A es entonces un elemento de B, y A hereda todas las
propiedades y definiciones de B.
EquivalentClass: Este axioma indica equivalencia. Cuando A es equivalente a
B ambas clases comparten las mismas definiciones, los elementos de A
pertenecen a B y viceversa.
DisjoinWIth: Este axioma indica disyunción. Cuando A es disjunto de B, ningún
elemento de A pertenece a B y viceversa.
A.1.3 Enumeraciones
Las enumeraciones son clases que definen una lista de individuales como instancias de
la clase. Por ejemplo, permite definir la clase Continent de la siguiente manera:
<owl:Class rdf:ID="Continent">
<owl:oneOf rdf:parseType="Collection"> <owl:Thing rdf:about="#Europa"/> <owl:Thing rdf:about="#Africa"/> <owl:Thing rdf:about="#America"/> <owl:Thing rdf:about="#Oceania"/> <owl:Thing rdf:about="#Asia"/> <owl:Thing rdf:about="#Antartida"/>
</owl:oneOf> </owl:Class>
A.1.4 Restricciones
Las restricciones permiten agregar información sobre las propiedades de una clase
particular. Este tipo de especificación puede indicar la existencia de una propiedad
específica o la cardinalidad de la misma. Por ejemplo, a la clase Father se le puede
agregar la restricción de tener al menos un hijo:
<owl:Class rdf:ID="Father">
<rdfs:subClassOf> <owl:Restriction>
<owl:onProperty rdf:resource="#hasChild"/> <owl:minCardinality>1</owl:minCardinality>
</owl:Restriction> </rdfs:subClassOf> </owl:Class>
APENDICE A. OWL EN DETALLE
77
A.1.5 Intersecciones, uniones y complementos
Por último se puede definir una clase a partir de otras clases ya definidas. OWL permite
definir una clase a partir de otras clases mediante los siguientes operadores:
IntersectionOf: La clase se define como la intersección de otras clases. Por
ejemplo, si A se define como la intersección de B y C. Todos los elementos de A
pertenecerán a las clases B y C al mismo tiempo.
UnionOf: La clase se define como la unión de otras clases. Por ejemplo, si A se
define como la intersección de B y C. Todos los elementos de A pertenecerán a
B, a C o a B y C al mismo tiempo.
ComplementOf: La clase se define como cualquier elemento del universo que
no pertenezca a otra clase. Si A se define como el complemento de B, cualquier
elemento que no pertenezca a B, pertenece a A.
A.2 Propiedades
Las propiedades permiten definir relaciones entre clases dominio y clases de alcance.
Por ejemplo, teniendo la clase Forecast y la clase Temperature, se puede indicar la
relación entre el pronóstico y la temperatura como una relación de hasTemperature.
<owl:ObjectProperty rdf:ID="hasTemperature">
<rdfs:domain rdf:resource="#Forecast"/> <rdfs:range rdf:resource="#Temperature"/>
</owl:ObjectProperty>
Pueden definirse más detalles acerca de una propiedad mediante axiomas que las
relacionen con otras propiedades o características lógicas y cardinales.
A.2.1 Axiomas de propiedades
Los axiomas de propiedades indican relaciones entre un par de propiedades. OWL
define tres tipos de axiomas de propiedades:
SubPropertyOf: Indica que una propiedad es una subpropiedad de otra. Por
ejemplo, la propiedad hasMother es una subpropiedad de hasParent, por lo tanto
todos los valores de hasMother pertenecen también a hasParent.
EquivalentProperty: Indica que ambas propiedades son equivalentes y poseen
los mismos valores.
APENDICE A. OWL EN DETALLE
78
InverseOf: Indica que si una propiedad posee dos valores en una dirección, la
propiedad inversa posee los mismos valores en la dirección contraria. Por
ejemplo, la propiedad hasParent es inversa a la propiedad hasChild.
A.2.2 Características cardinales
Una propiedad puede tener restricciones cardinales. OWL define dos características de
este tipo:
FunctionalProperty: Indica que para cada valor x, no pueden existir dos valores
y1, y2 tales que se cumpla que la propiedad posee los valores (x,y1) y (x,y2).
InverseFunctoinalProperty: Indica que para cada valor y, no pueden existir dos
valores x1, x2 tales que se cumpla que la propiedad posee los valores (x1,y) y
(x2,y).
A.2.3 Características lógicas
Se pueden definir características de una propiedad para con ella misma. OWL permite
dos tipos de características:
TransitiveProperty: Indica transitividad en la propiedad. Si existen los pares
(x,y) e (y,z) entre los valores de la propiedad, también existe entonces el par
(x,z).
SymmetricProperty: Indica que la propiedad es simétrica. Si existe el par (x,y)
entre los valores de la propiedad, también existe entonces el par (y,x).
A.2.4 Individuales
Son hechos del mundo identificables, que pueden pertenecer a una clase o poseer
ciertas relaciones con otros individuales. Por ejemplo, si se tiene la clase Ocean, un
individuo podría ser Atlantic, que a su vez pertenecería a la clase Ocean.
<Ocean rdf:ID="Atlantic"/>
A su vez puede estar relacionado con otros individuales, como por ejemplo, la Ópera
Tosca tiene como compositor a Giacomo Puccini:
<Opera rdf:ID="Tosca">
<hasComposer rdf:resource="#Giacomo_Puccini"/> </Opera>
APENDICE A. OWL EN DETALLE
79
Los individuales tienen identidades, por lo que pueden diferenciarse o no, de otros
individuales. Para esto OWL define dos propiedades:
SameAs: Indica que ambos individuales referencian al mismo elemento.
DifferentFrom: Indica que los individuales referencian a distintos elementos.
A.3 Documentos
Para la correcta definición de los servicios es necesario definir la estructura que los
documentos de OWL deben poseer.
Las clases ServiceProfile, ServiceModel y ServiceGrounding son los rangos respectivos
de las propiedades “presenta”, “es descrito mediante”, y “soporta”. Cada instancia de un
servicio presenta una descripción de ServiceProfile, se describe mediante una
descripción de ServiceModel y da soporte a una descripción de ServiceGrounding. Los
detalles de estos elementos pueden variar ampliamente de un tipo de servicio a otro y
cada una de estas perspectivas proporciona un tipo de información esencial sobre los
servicios.
Por lo tanto, las clases enumeradas previamente junto a las clases Ontology y
ServiceProcess encargadas de proveer la ontología y especificar la interacción con cada
servicio, definen el conjunto de servicios que serán procesados e interpretados por el
algoritmo de planning para realizar la composición. Estas secciones son detalladas a
continuación y cada una se corresponde con su archivo específico. También se explica
y ejemplifica una de las maneras en las que se puede llevar a cabo la definición de cada
documento.
A.3.1 Ontology
La ontología de los servicios sirve como guía para todos los servicios que van a ser
definidos, por lo tanto es necesario que se especifiquen todas las clases, acciones de
clases, propiedades y elementos necesarios que serán utilizados por los procesos y
servicios en sus correspondientes documentos. En la siguiente imagen pueden verse
varios de estos elementos:
APENDICE A. OWL EN DETALLE
80
Figura A.1. Ejemplo del contenido del archivo Ontology.
En la figura A.1 se puede apreciar la definición de tres clases, dos de ellas son subclases
de Temperature especificando semánticamente una temperatura particular. También se
define una propiedad funcional hasTemperature que posee como dominio la clase City
y rango Temperature.
A.3.2 Service Profile
El perfil de servicio dice "lo que hace el servicio", es decir, características no funcionales
del servicio de manera que un agente de búsqueda de servicios pueda determinar si el
servicio satisface sus necesidades de manera adecuada. Esta forma de representación
incluye una descripción de lo que se logra por el servicio, las limitaciones en la
aplicabilidad del servicio y la calidad del servicio, y los requisitos que el solicitante del
servicio debe satisfacer para usar el servicio con éxito.
APENDICE A. OWL EN DETALLE
81
Por otro lado, los campos referidos a varias de las propiedades de interés se encuentran
actualmente deprecadas8, si bien no prohíben su utilización es recomendable no
utilizarlos. Por este motivo se decidió utilizar algunos de los elementos existentes y
agregar dos campos simples con el objetivo de definir otros aspectos correspondientes
con el perfil del servicio:
CostOfService: Este campo indica si el servicio en cuestión posee algún costo
monetario para los usuarios. Los posibles valores son withCost o nonCost.
Availability: Indica la disponibilidad del servicio en porcentaje. Los posibles
valores son números enteros que van desde 0 hasta 100.
A continuación se muestra un ejemplo de cómo realizar la definición de diferentes
perfiles de servicios.
8 http://www.daml.org/services/owl-s/1.2/ProfileDeprecatedElements.owl
APENDICE A. OWL EN DETALLE
82
Figura A.2. Descripción del perfil de un servicio en el archivo Profile.
En la figura A.2 se puede apreciar cómo quedan definidos dos perfiles diferentes, uno
privado y otro público. El perfil público tiene una disponibilidad de 65 y no posee costo,
en cambio, el perfil privado tiene una disponibilidad de 95 pero con un costo asociado.
A.3.3 Service Grounding
Los servicios definidos deber ser asociados a un perfil en particular para que la
aplicación sea capaz de comprenderlos, para esto sirve el documento Grounding.
APENDICE A. OWL EN DETALLE
83
En esencia, en el documento Grounding se especifica los detalles de cómo un agente
puede acceder a un servicio, se especifican los servicios existentes y se los relaciona
con un perfil determinado. En la figura A.3 se puede apreciar la definición de dos
servicios así como su relación un perfil particular.
Figura A.3. Ejemplo del contenido del archivo Grounding.
A.3.4 Service Model
En el modelo del servicio se busca identificar y asociar cada uno de los servicios con su
respectivo Grounding. La figura A.4 muestra la asociación de un perfil privado al
grounding privado definido en las secciones anteriores.
Figura A.4. Ejemplo de la asociación de un servicio con su respectivo grounding.
A.3.5 Service Process
En este documento se definen los procesos de los servicios. Estos procesos son de
gran interés para el proyecto ya que definen la semántica del servicio web. Si bien OWL-
APENDICE A. OWL EN DETALLE
84
S define procesos compuestos y procesos atómicos, nos enfocaremos principalmente
sólo en los procesos atómicos.
Los procesos atómicos definen los servicios web de manera individual. Cada proceso
atómico puede tener inputs, preconditions, local variables, outputs y varios otros
posibles resultados:
Inputs: Representan los datos que necesarios a la hora de ejecutar el servicio.
Local variables: Sirven para representar datos necesarios o condiciones
necesarias para la ejecución del servicio.
Preconditions: Son condiciones que deben cumplirse para que el servicio
pueda ejecutarse correctamente.
Outputs: Representan los datos devueltos por el servicio luego de una ejecución
exitosa.
Por ejemplo, en un proceso de compra de un boleto de avión, los inputs podrían ser el
número de asiento que se desea, los datos del usuario y el número de la tarjeta de
débito. Una local variable podría representar el saldo asociado a esa tarjeta de débito,
necesario para definir como precondición que el saldo de esa tarjeta sea mayor al valor
del boleto. Los outputs podrían ser los datos de la compra y la confirmación de la misma.
Además, el proceso puede definir distintos posibles resultados que se pueden dar en
distintas condiciones. Cada uno de estos resultados posee conditions en las cuales
ocurren, outputs adicionales y efects producidos por el resultado:
Conditions: Son las condiciones bajo las cuales se da el resultado del servicio.
Outputs: Representan los datos devueltos por el servicio. La salida final está
dada por el conjunto de outputs del proceso y el conjunto de outputs del
resultado.
Efects: Indican los efectos producidos por el resultado.
A.4 Definiciones de las ontologías
Durante el desarrollo de la tesis se encontraron dos maneras diferentes de realizar la
definición de las ontologías. Inicialmente, los procesos definidos en OWL contaban con
los predicados hasvalue y hasrepresentation (A.2.1). Estos dos predicados nos permiten
definir el valor y la representación que posee una variable en cuestión.
El inconveniente que acarrea esta manera de definir los procesos radica en el
incremento del número de acciones generadas luego de realizar la conversión al
algoritmo de planeamiento. En consecuencia, los árboles que se generan internamente
APENDICE A. OWL EN DETALLE
85
en los algoritmos de planeamiento crecen demasiado, y por consiguiente, el tiempo
necesario para obtener una se ve incrementado.
Debido a esto, se decidió cambiar la manera en la escritura de la semántica de los
servicios de la siguiente forma:
En lugar de crear representaciones para cada una de las clases y utilizarlas junto con el
predicado hasrepresentation, se definen subclases de las clases padre. De esta manera,
el nombre de la clase es la encargada de proveer la semántica necesaria para identificar
el tipo de la misma. Por ejemplo, si tenemos la clase Temperature y definimos la clase
TemperatureCelsius como una subclase de Temperature, por contexto se puede deducir
que la misma es una temperatura con representación en grados centígrados. De esta
forma se ahorra el uso de los predicados hasvalue y hasrepresentation, ya que el valor
está contenido dentro de la clase o subclase y la representación se infiere por contexto.
Como consecuencia, el cambio de escritura en los procesos de OWL modificó el tiempo
necesario para procesar y obtener una solución por el algoritmo de planeamiento.
Inicialmente, el algoritmo tardaba aproximadamente 45 minutos en obtener una solución
para un conjunto de 10 servicios. Luego del cambio de representación y utilizando el
mismo número de servicios, el tiempo necesario para obtener una solución fue de
apenas 2 minutos. Cabe destacar que en ambos casos la solución se encuentra
compuesta por los mismos servicios.
86
Bibliografía
Ugur Kuter, Evren Sirin, Bijan Parsia, Dana Nau, James Hendler, “Information gathering
during planning for Web Service composition”, University of Maryland, College Park, MD
20742 USA, 2005.
David Booth, Hugo Haas, Francis McCabe, Eric Newcomer, Michael Champion, Chris
Ferris and David Orchard, “Web Services Architecture”, 2004.
Alonso, G., Casati, F., Kuno, H., Machiraju, V., “Web Services. Concepts, Architectures
and Applications”, Springer-Verlag, Berlin, Heidelberg, 2004.
Daniel S. Weld, “An Introduction to Least Commitment Planning”, Department of
Computer Science and Engineering University of Washington Seattle, WA 98195, 1994.
Luis Berdun, Analía Amandi, Marcelo Campo, “An agent specific planning algorithm”,
ISISTAN, Facultad de Ciencias Exactas, Universidad Nacional del Centro de la Pcia. Bs.
As., Campus Universitario, Paraje Arroyo Seco, Tandil, Argentina, 2011.
Dana Nau, Tsz-Chiu Au, Okhtay Ilghami, Ugur Kuter, J. William Murdock, Dan Wu,
Fusun Yaman, “SHOP2: An HTN Planning System”, Dept. of Computer Science,
University of Maryland, College Park, MD 20742 USA, 2003.
Alfonso Gerevini and Derek Long, “Plan Constraints and Preferences in PDDL3, The
Language of the Fifth International Planning Competition”, University of Brescia (Italy),
University of Strathclyde (UK), 2005.
Armando Ordoñez, Juan C. Corrales (University of Cauca, Colombia), Paolo Falcarin
(University of East London), “Natural language processing based services composition
for environmental management”, United Kingdom, 2012.
Sayed Gholam Hassan Tabatabaei, Wan Mohd Nasir Wan Kadir, Suhaimi Ibrahim,
“Semantic Web Service Discovery and Composition Based on AI-Planning and Web
Service Modeling Ontology”, Department of Software Engineering, Faculty of Computer
Science and Information Systems, University of Technology Malaysia, 2008
BIBLIOGRAFIA
87
V. Portchelvi, V. Prasanna Venkatesan, G. Shanmugasundaram, “Achieving Web
Services Composition – a Survey”, Dept. of Banking Technology, Pondicherry University,
Pondicherry, 600 000, South India, 2012.
Naiwen Lin, “Web Service Composition with User Preferences”, Department of Computer
Science, University of Maryland, College Park, MD 20742, USA, 2008.
K. S. May Chan, Judith Bishop, and Luciano Baresi; University of Pretoria, “Survey and
Comparison of Planning Techniques for Web Services Composition”, Department of
Computer Science, 2007.
https://www.w3.org/TR/wsdl#_wsdl
Dieter Fensel, Christoph Bussler, “Web Service Modeling Framework”, Division of
Mathematics and Computer Science, Faculty of Sciences, Vrije Universiteit Amsterdam
(VU), De Boelelaan 1081a, 1081 HV Amsterdam, Netherlands, Oracle Corporation, 500
Oracle Parkway, Redwood Shores, CA 94065, USA, 2002.
https://www.w3.org/Addressing/URL/uri-spec.html
T. Gruber: “A translation approach to portable ontology specifications, Knowledge
Acquisition”, 1993.
https://www.w3.org/Submission/WSMO/
Steven M. LaValle, “Planning Algorithms”, University of Illinois, 2006.
Penberthy, J. S. and Weld, D., “UCPOP: A Sound, Complete, Partial-Order Planner for
ADL”, Third International Conference on Knowledge Representation and Reasoning
(KR-92), Cambridge, MA, October 1992.
Evren Sirina, Bijan Parsiab, Dan Wua, James Hendlera, Dana Naua, “HTN planning for
Web Service composition using SHOP2”, University of Maryland, College Park, MD
20742, 2004.
Guillermo Rodríguez, Álvaro Soria, Marcelo Campo, “Artificial intelligence in service-
oriented software design”, ISISTAN Research Institute (CONICET-UNICEN), Argentina,
2015.
https://www.w3.org/Submission/OWL-S/
http://www.daml.org/services/owl-s/1.2/ProfileDeprecatedElements.owl
BIBLIOGRAFIA
88
Daniela Barreiro Claro, Patrick Albers, Jin-Kao Hao, “Web Services
Composition”, University of Angers, Boulevard Lavoisier, 49045, Angers cedex 01
France, 2006.
B. Jaya Kaviya, G. Selvakumar, “A Survey on RESTful Web Services Composition”,
Dept. Of CSE, Sri Shakthi Institute of Engineering and Technology, India, 2016.
Pawel Stelmach. “Service Composition Scenarios in the Internet of Things Paradigm”.
Luis M. Camarinha-Matos; Slavisa Tomic; Paula Graça. 4th Doctoral Conference on
Computing, Electrical and Industrial Systems (DoCEIS), Apr 2013, Costa de Caparica,
Portugal. Springer, IFIP Advances in Information and Communication Technology, AICT-
394, pp.53-60, 2013, Technological Innovation for the Internet of Things, 2013.
http://www.jdom.org/
