Web Services Composition Optimizer (WSCOv1.0)

Técnicas de Optimización de Composiciones de
Servicios Web (WSCO)

España Vargas J., García Hurtado F.J., Lozano Reyes M., Martín Checa J.A.

Máster en Ingeniería del Software e Inteligencia Articial (Universidad de Málaga) Técnicas de
Base de Datos y de Programación Distribuida para la Web

Resumen Los servicios web se están utilizando cada vez más en la implementación
de software distribuido, debido a que la interfaz de datos en XML hace que la im-
plementación de servicios web permita el desarrollo de procesos de negocios inter-
operables [4]. En este artículo introducimos un framework para la optimización de
composiciones de servicios web notados semánticamente, consistente en un GUI
desde el cual el usuario puede congurar sus experimentos, llevados a cabo por
jMetal, el cual hace uso del algoritmo de mutación NSGA-II. El framework que
presentamos se basa en los conceptos recogidos en en el artículo Semantic Web
Services Composition Optimized by Multi-Objective Evolutionary Algorithms [3].
En la sección 5 recogemos una comparativa para mono-objetivo entre el algorit-
mo desarrollado FMJ2 y el NSGA-II, en función al número de iteraciones y a la
población, así como los resultados obtenidos de la optimización multiobjetivo con
el algoritmo NSGA-II.

1. INTRODUCCIÓN

La composición de servicios web consiste en la generación de servicios complejos a
partir de servicios pre-existentes de forma que se satisfagan las necesidades del usuario
nal, existiendo un compromiso entre el conjunto de objetivos y las restricciones jadas
por el propio usuario. La optimización sigue siendo un problema importante ya que hay
que tener en cuenta que no se trata de mostrar unos resultados, sino que hay que garan-
tizar que las soluciones proporcionadas deben ser las óptimas. Desde esta perspectiva,
los lenguajes de servicios web semánticos como, por ejemplo, OWL-S [3] proporcionan
elementos para solucionar problemas de composición de servicios. Brahim B. propone un
nuevo algoritmo genético (GA) para abordar el problema de la optimización de la com-
posición de servicios para la web semántica. Su objetivo es proporcionar una solución
semiautomática para múltiples objetivos y restricciones, proporcionando al usuario un
conjunto de composiciones que responden a los objetivos de manera diferente, dejando la
decisión nal para el usuario.
La composición de los servicios tiene que cumplir múltiples objetivos tales como la
minimización de costes, la reducción del tiempo de respuesta y/o maximizar la satisfacción
del consumidor.
Este artículo sigue la siguiente estructura. En la sección 2 deniremos el problema
de la optimización de composición de servicios web. En la sección 3 presentaremos el
modelado del problema para adaptarlo a los requerimientos para poder procesarlo con
jMetal. En la sección 4 recogeremos los trabajos realizados con jMetal. En la sección 5

los resultados obtenidos de los experimentos realizados. En la sección 6 enumeraremos
algunos de los trabajos relacionados. Y en la sección 7 las conclusiones obtenidas y los
trabajos futuros que se pueden realizar.

2. DEFINICIÓN DEL PROBLEMA

El enfoque se centra en la composición de la optimización del servicio en respuesta
a consultas que recogen múltiples objetivos. El lenguaje que han adoptado para la de-
scripción de los servicios web es OWL-S. Para hacer más fácil el proceso, se asume que
las consultas del usuario se pueden formalizar por modelos abstractos de OWL-S. Se de-
ne una consulta como una terna R=T, C, B, donde T es la consulta OWL, C es el
conjunto de restricciones y B es el conjunto de objetivos que deben cumplirse. Tanto las
restricciones como los objetivos pueden ser de tres clases: (a) en relación a un servicio,
(b) en relación con una base de datos manipulados por un servicio y (c) en relación con
la composición. Estos elementos se utilizan durante el proceso de composición de opti-
mización y se puede descomponer en cuatro etapas (ver gura 1): (1) descomposición de
la consulta, (2) selección de los servicios, (3) la creación del espacio de búsqueda y (4) la
optimización de la composición. En la gura 1 se recoge un esquema del problema:

Figura 1.- Esquema del problema

2.1. Descomposición de la consulta

Como hemos mencionado anteriormente la consulta está compuesta por la descripción
de la solicitud, por el conjunto de restricciones a satisfacer y por el conjunto de objetivos
a cumplir.

2.2. Selección de servicios

Los servicios pueden clasicarse en tres tipos: activos, informativos y de entarda/salida
de datos. La selección de servicios debe ser compatibles con las restricciones y objetivos
propuestos. Los que no son compatibles son eliminados de la selección.

2.3. Creación del espacio de búsqueda

Una vez ltrados los servicios, y rechazados los que no cumplen las restricciones, se
genera la composición del espacio de búsqueda, siendo el conjunto de posibles soluciones.
Una composición de servicios puede ser representado como un grafo en el que cada camino
representa una composición de servicio posible. El grafo está formado por un número de
capas determinadas en el GUI, donde cada una de ellas está formada por un número
aleatorio de servicios.

2.4. Optimización de la composición

A cada solución se denomina individuo. Del grafo del espacio de búsqueda se obtendrán
todas las soluciones individuales de forma que las relaciones entre los servicios cumplan
la función de correspondencia establecida Matching Function, es decir, si los puertos de
subquery-servicio o servicio-servicio son o no compatibles. La bondad está representada
por el tness que viene a decir cómo de bueno es un determinado servicio.

3. MODELADO DE LOS SERVICIOS WEB

Para la simulación del sistema hemos implementado un GUI con PHP/XML en la
que nos ofrece un interfaz gráco donde el usuario dene los parámetros, congurando
el tamaño y las características de la población. El GUI está formado por los siguientes
formularios:

Figura 2.- Generación automática de las subconsultas y servicios web

En la gura 2 del GUI existen parámetros tanto para las subconsultas como para los
servicios web, como son: la población, el tipo de datos y el valor máximo y mínimo de los
puertos de entrada y salida, así como tipo y el rango de valores para la función tness
para cada servicio web. Permite seleccionar hasta tres funciones tness (multiobjetivo),
si queremos trabajar con mono-objetivo seleccionamos únicamente una una función t-
ness. El botón superior de Reset reinicia el formulario a los valores iniciales, y el icono
justo a la derecha del mismo es un enlace a este artículo.

Figura 3.- Parámetros para la función de correspondencia (Matching Functions)

En la Figura 3 denimos los valores de la función de correspondencia (subquery-
servicio web) y (servicio web-servicio web).

Figura 4.- Generación automática de consultas

En esta gura se muestra el formulario correspondiente a la introducción de los valores
del número máximo de subconsultas y la probabilidad permitida para las subconsultas
activas (ASQ)y para las subconsultas informativas (ISQ).
Una vez congurados todos los parámetros se genera de forma automática la base de
datos XML con: las subconsultas activas, subconsultas informativas, servicios activos y
los servicios informativos y servicios de datos de entrada/salida (Figura 5).

Figura 5.- Modelado

3.1. Descomposición de la consulta

A través del formulario de la Figura 2 se congura el número de las subconsultas de
cada tipo así como el número de servicios Web, y los tipos y rangos de los puertos de
entrada y salida, así como los valores tness para el caso de los servicios web. Cada vez
que se pulsa el botón 'Generate Subqueries and Web Services' del GUI se sobreescriben los

cheros XML con los nuevos parámetros. En la gura 6 mostramos el aspecto de dos tipos
de cheros XML para los servicios web activos y para la función de correspondencias. En
caso de que en la gura 2 hubiésemos seleccionado únicamente una función tness, no
aparecerían las líneas del tness_2 y tness_3 en el archivo activate_web_services.xml.

Figura 6.- Aspecto de los cheros XML

3.2. Selección de servicios

Para la selección de servicios se ha implementado una función de correspondencia con
bipuertos: de entrada, salida y valores reales (solo para los SW). Para cada subconsulta
se genera una lista de servicios web que satisfacen su condición dada por la función de
correspondencia, con lo cual tenemos tantas listas de servicios web como se hayan denido
en el interfaz gráco. La longitud de cada una de estas listas es aleatoria. Es de notar
que un servicio informativo siempre irá seguido por un servicio de E/S de datos el cual
satisface al petición de información del primero.

3.3. Creación del espacio de búsqueda

En el chero query.xml se recogen todas las subconsultas generadas. Para cada una
de ellas hay que seleccionar los servicios web compatibles. Si son del tipo A hay que
localizarlos en el chero active_web_services.xml y si son del tipo I en el chero infor-
mative_web_services.xml, siempre cumpliendo la función de correspondencia almacena-
da en matching_functions.xml. Combinando todos estos elementos (subqueries, servicos
web y restricciones) es posible generar nuestro 'espacio de soluciones', representable por

ejemplo a modo de grafo, indicando todas las posibles soluciones a nuestro problema de
partida. En la gura 7 se muestra a modo de ejemplo y esquemáticamente como quedaría
representado el espacio de soluciones para una consulta formada por quince subconsultas.
Para ello hemos implementado en el GUI un botón que genera dicho espacio de soluciones,
en función a los parámetros introducidos. Evidentemente no mostramos aquí los servicios
de datos de I/O ya que éstos entran en juego durante la propia optimización.

Figura 7.- Espacio de búsqueda para una query con 10 subconsultas

3.4. Optimización de la composición

Una vez obtenido el espacio de soluciones, hay que optimizarlas. Para ello hemos
diferenciado claramente dos casos:

Algoritmo FMJ2: hemos implementado un algoritmo para el caso exclusivo de mono-
objetivo. Este algoritmo genera dos soluciones de forma aleatoria, cumpliendo las
restricciones de la función de correspondencia, a continuación cruzamos las dos solu-
ciones para generar una tercera y quedarnos con la mejor. En la siguiente iteración
generamos otra población de forma aleatoria y la cruzamos con la obtenida de la
iteración anterior, y volvemos a elegir la más óptima de entre las tres posibles. Y así
hasta el número de iteraciones establecido. En la gura 8 se recoge el diagrama de
clases utilizado para la implementación de dicho algoritmo.

Figura 8.- Diagrama de clases

Adaptación del algoritmo NSGA-II: hemos adaptado el algoritmo NSGA-II existente
en jMetal, para que admita un vector, con objeto de poder optimizar el problema.
Este algoritmo realiza tres operaciones: cruce, mutación y selección. Dicho algoritmo
sirve para optimizar problemas tanto mono-objetivos como multiobjetivos.

Para que la selección del algoritmo de optimización pueda ser seleccionado por el usuario,
se ha incorporado en el GUI un pequeño formulario (gura 9), a través del cual, se
puede especicar el número de iteraciones, la población y el algoritmo a ejecutar: FMJ2
o NSGA-II.

Figura 9.- Optimización de la Composición de Servicios Web

4. ANÁLISIS CON JMETAL

El jMetal es un marco de trabajo para la optimización multi-objetivo mediante la uti-
lización de algoritmos metaheurísticos implementados en Java [1]. Para nuestro problema

el algoritmo que mejor se adaptaba es el NSGA-II, aunque hemos tenido que adaptarlo a
nuestras necesidades:

En primer lugar hemos modicado la clase NGSAII_main, renombrándola por NS-
GAII_main_WSComposition.java. Esta clase, además de contener el método main,
se encarga de congurar el algoritmo NGSA-II, modicado para nuestro propósito.
El algoritmo se congura con la llamada siguiente:
algorithm = new NSGAII(problem,webServicesComp);
Además se conguran los diferentes operadores que vamos a utilizar, de la siguiente
manera:

//Operador de cruce.
crossover = CrossoverFactory.getCrossoverOperatorWS(WS_Crossover, webServicesComp);
crossover.setParameter(probability,0.9); //Probabilidad de Cruce
crossover.setParameter(distributionIndex,20.0);
//Operador de mutación.
mutation = MutationFactory.getMutationOperatorWS(WS_Mutation, webServicesComp);
mutation.setParameter(probability,1.0/problem.getNumberOfVariables());
mutation.setParameter(distributionIndex,20.0);
selection = SelectionFactory.getSelectionOperator(BinaryTournament);
La ejecución del algoritmo se lanza de la siguiente manera.
SolutionSet population = algorithm.execute();
Por último se almacenan los resultados en los cheros VAR y FUN.

La clase NSGAII.java contiene el algoritmo evolutivo en cuestión. Su método execute()
consiste en un bucle que se itera un número determinado de veces y que devuelve
un conjunto de soluciones. Esta clase utiliza los operadores de mutación, cruce y
selección que hemos usado en el apartado anterior. El operador de selección no lo
hemos modicado, es decir, hemos usamos BynaryTournament, que consiste en
una selección pseudoaleatoria de los individuos. Los operadores de cruce y mutación,
si los hemos modicado.
La clase WS_Crossover.java, implementa el operador de cruce, intercambiando las
posiciones de 2 array de identicadores de servicios Web, dando como salida 2
individuos cruzados.
La clase WS_Mutation.java, implementa el operador de cruce. El método execute()
toma una posición de un individuo y cambia el identicador del servicio por un número
generado de forma pseudoaleatoria.
Las clases CrossoverFactory, IntSolutionType, y MutationFactory, que aparecen en
jMetal, las hemos adaptado para que contemplen los operadores nuevos que hemos
denido.
La clase WS_Composition_Problem modela el problema. En esta clase hemos mod-
icado el método evaluate(). Este método se encarga de calcular el tness asociado
a cada uno de los individuos.
La clase WebServicesComposition.java encapsula todas las operaciones que se realizan
con los Servicios Web, es decir, se encarga de obtener los individuos, generar el espacio
de búsqueda, evaluar las soluciones, etc.

Hemos tenido que generar una clase nueva, denominada WSXML2DATA.java, que
se encarga de generar estructuras de datos a partir de los cheros XML, es decir,
funciona como un parseador.

En cuanto a la funcionalidad podemos distinguir cinco pasos:

1. Examinar el archivo query.xml.
2. Para cada subquery del archivo anterior:

Si es de tipo A: buscar en el archivo active_web_services.xml los AWS
compatibles (según la matching function adecuada, almacenada en match-
ing_functions.xml).
Si es de tipo I: buscar en el archivo informative_web_services.xml los IWS
compatibles (según la matching function adecuada, almacenada en match-
ing_functions.xml)

3. Generar una población inicial.
4. Aplicar el algoritmo genético NSGA-II mutando alguno de sus elementos, pero siempre
comprobando que se cumple la matching function correspondiente.
5. Ir computando los valores de tness de cada individuo obteniendo en cada paso
el correspondiente valor de tness global, que es el que indica la bondad de la
composición de servicios actual.

5. RESULTADOS DEL EXPERIMENTO

Dentro de los experimentos realizados hay que distinguir entre la optimización mono-
objetivo y la optimización multiobjetivo.

5.1. Optimización mono-objetivo

Como hemos mencionado en la sección 3.4, para la optimización mono-objetivo hemos
desarrollado el algoritmo FMJ2 y hemos adaptado el NSGA-II. En las grácas siguientes se
muestra una comparativa en función al número de iteraciones y el tamaño de la población
generada.

Gráca 1.- Comparativa para 2.500 iteraciones y 50 de población



Analizando las grácas anteriores podemos armar que para poblaciones pequeñas y
un número reducido de iteraciones el algoritmo FMJ2 (AE) proporciona mejores resul-
tados que el algoritmo NSGA-II. En cambio, a mayor número de iteraciones y mayor
población, el NSGA-II mejora considerablemente su tness con respecto al FMJ2, al-
canzando un equilibrio entre ambos con unas 7.500 iteraciones y una población de 250.

Profundizando en el algoritmo NSGA-II, en las grácas siguientes se recoge la evolu-
ción del mismo en función a la población y al número de iteraciones.

Gráca 4.- Valor medio del tness (en 20 ejecuciones) en función del tamaño de la
población

Gráca 5.- Valor medio del tness (en 20 ejecuciones) en función del número de
iteraciones

Observando la gráca 4 podemos deducir que el tness aumenta de forma exponencial
hasta una población de 300 individuos, permaneciendo estable a partir de dicho punto.
De la gráca 5 podemos deducir que el tness mejora de forma lineal hasta las 12.500
iteraciones permaneciendo estable a partir de ese punto.

5.2. Optimización multiobjetivo

Para la optimización multiobjetivo hemos utilizado exclusivamente la adaptación del
algoritmo genético NSGA-II, proporcionado en jMetal [1]. No se han denido pesos para
cada objetivo, por lo que cada uno tendrá la misma importancia. Las grácas obtenidas
son las siguientes:

Gráca 6.- Resultados para 2 objetivos para 2.500 iteraciones y 150 de población

En la gráca 6 se muestra los resultados obtenidos para dos objetivos y una población
de 150, donde después de 2.500 iteraciones podemos deducir que cuando se optimiza uno
de los objetivos se penaliza el otro, y viceversa. La mayoría de los tness obtenidos se
concentran en valores similares para cada objetivo.

Gráca 7.- Resultados para 3 objetivos para 2.500 iteraciones y 150 de población

En la gráca 7 recogemos los resultados obtenidos para 3 objetivos y una población de
150, donde tras 2.500 iteraciones podemos comprobar que sucede algo similar a la gráca
biobjetivo.

6. TRABAJOS RELACIONADOS

Algunos de los trabajos relacionados más importantes son los siguientes:

1. M. Alrifai en la 18th International Wordl Wide Web Conference [6] propuso un méto-
do para optimizar la composición de servicios a través de la descomposición de la
consulta del usuario en una secuencia de subconsultas, de forma que seleccionan los
mejores servicios para cada subconsulta en base a los objetivos propuestos. Con ello
consigue reducir el problema a un problema mono-objetivo, reduciendo el tiempo de
respuesta y proporcionando soluciones cercanas a la óptima. Es útil para aplicaciones
que requieren de soluciones en tiempo real.

2. Otro enfoque que se recoge en [7] está basado en la utilización de algoritmos genéticos
para la optimización de la composición e implementación de los servicios para redes
móviles ac-doc.
3. Cuando el número de servicios web es muy amplio y el número de restricciones tam-
bién, lo mejor es utilizar un algoritmo genético híbrido para la detección del servicio
óptimo [5].
4. En [2] se presenta un algoritmo evolutivo (MOEA) que pretende resolver el proble-
ma de la optimización de la composición dinámica, presentando resultados óptimos
incluso cuando el sistema sufre cambios dinámicos en los datos.

7. CONCLUSIONES Y TRABAJOS FUTUROS

7.1. Conclusiones

Con este trabajo hemos modelado el problema de la optimización de Servicios Web.
Partiendo de la base del artículo Semantic Web Services Composition Optimized by
Multi-Objective Evolutionary Algorithms [3] hemos abstraído el problema, lo hemos
modelado y lo hemos optimizado a través de un algoritmo mono-objetivo (FMJ2) y mul-
tiobjetivo con el NSGA-II, proporcionado por jMetal, aunque hemos tenido que adaptarlo
a nuestras necesidades. Entre las conclusiones más importantes podemos destacar:

El algoritmo FMJ2 (mono-objetivo) desarrollado proporciona mejores resultados que
el NSGA-II cuando la población es inferior a 250, para poblaciones superiores es el
NSGA-II el que proporciona mejores resultados.

7.2. Trabajos futuros

El modelo presentado es una abstracción simplicada de la realidad generando el
espacio de búsqueda de forma automática. Entre las posibles mejoras podemos destacar:

1. La sustitución de los parámetros de los puertos de entrada y salida (reales) por un
vector de valores (uno por cada parámetro que dene a un WS), y elaborar una
función de correspondencia más compleja que considere la compatibilidad entre cada
par de elementos uno a uno de dos vectores (output[] e input[]), y denir un array
para los tness.
2. La modicación del algoritmo FMJ2 para que soporte multiobjetivo, y así poder
compararlo con el NSGA-II.
3. La utilización de un modelo de datos más complejo y el a la realidad, por ejemplo
el planteado por uno de los profesores de la asignatura.
4. La automatización del ploteado de los resultados obtenidos, desde el GUI.
5. Para cada función tness se podría poner un peso que representa la importancia de
cada función con respecto a las otras. La suma de los pesos debe ser 1.

Referencias

1. J. J. Durillo A. J. Nebro. Jmetal 3.1 user manual. 2010.

2. I. Jars T. Latour F. Guinand B. Batouche, Y. Naudet. A multi-objetive evolutionary algorithm
to optimize the dynamic composition of semantic web services. Public Research Center Henri
Tudor.
3. F. Guinand B. Brahim, Y. Naudet. Semantic web services composition optimized by multi-
objective evolutionary algorithms. Fifth International conference on Internet and Web Appli-
cations and Services, 2010.
4. J. Tuya y C. de la Riva J. García-Fanjul. Generación de casos de prueba para composiciones
de servicios web especicadas en bpel. PRIS, 2006.
5. IEEE y L. Ai M. Tang, S. Member. A hybrid genetic algorithm for the optimal constrained
web service selection problem in web service composition. World Congress on Computational
Intelligence, 2010.
6. M. Alrifai y T. Risse. Combining global optimization with local selection for ecient qos-aware
service composition. 18th International Wordl Wide Web Conference, 2009.
7. Y. Berbers Y. Vanrompay, P. Rigole. Genetic algorithm-based optimization of service com-
position and deployment. Association for Computing Machinery, 2008.

Web Services Composition Optimizer (WSCOv1.0)

Más contenido relacionado

Similar a Web Services Composition Optimizer (WSCOv1.0) (20)

Último (20)

Web Services Composition Optimizer (WSCOv1.0)