Web Services Composition Optimizer (WSCOv1.0)
Upcoming SlideShare
Loading in...5
×
 

Web Services Composition Optimizer (WSCOv1.0)

on

  • 525 views

 

Statistics

Views

Total Views
525
Views on SlideShare
524
Embed Views
1

Actions

Likes
0
Downloads
8
Comments
0

1 Embed 1

http://www.slideshare.net 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Web Services Composition Optimizer (WSCOv1.0) Web Services Composition Optimizer (WSCOv1.0) Document Transcript

    • 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 apartir de servicios pre-existentes de forma que se satisfagan las necesidades del usuarional, existiendo un compromiso entre el conjunto de objetivos y las restricciones jadaspor el propio usuario. La optimización sigue siendo un problema importante ya que hayque 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] proporcionanelementos para solucionar problemas de composición de servicios. Brahim B. propone unnuevo 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ónsemiautomática para múltiples objetivos y restricciones, proporcionando al usuario unconjunto de composiciones que responden a los objetivos de manera diferente, dejando ladecisión nal para el usuario. La composición de los servicios tiene que cumplir múltiples objetivos tales como laminimización de costes, la reducción del tiempo de respuesta y/o maximizar la satisfaccióndel consumidor. Este artículo sigue la siguiente estructura. En la sección 2 deniremos el problemade la optimización de composición de servicios web. En la sección 3 presentaremos elmodelado del problema para adaptarlo a los requerimientos para poder procesarlo conjMetal. 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 enumeraremosalgunos de los trabajos relacionados. Y en la sección 7 las conclusiones obtenidas y lostrabajos 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 respuestaa 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 quelas 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 elconjunto de restricciones y B es el conjunto de objetivos que deben cumplirse. Tanto lasrestricciones 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 conla 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 dela consulta, (2) selección de los servicios, (3) la creación del espacio de búsqueda y (4) laoptimización de la composición. En la gura 1 se recoge un esquema del problema:
    • Figura 1.- Esquema del problema2.1. Descomposición de la consulta Como hemos mencionado anteriormente la consulta está compuesta por la descripciónde la solicitud, por el conjunto de restricciones a satisfacer y por el conjunto de objetivosa cumplir.2.2. Selección de servicios Los servicios pueden clasicarse en tres tipos: activos, informativos y de entarda/salidade datos. La selección de servicios debe ser compatibles con las restricciones y objetivospropuestos. 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, segenera 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 caminorepresenta una composición de servicio posible. El grafo está formado por un número decapas determinadas en el GUI, donde cada una de ellas está formada por un númeroaleatorio 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ántodas las soluciones individuales de forma que las relaciones entre los servicios cumplanla función de correspondencia establecida Matching Function, es decir, si los puertos desubquery-servicio o servicio-servicio son o no compatibles. La bondad está representadapor 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 laque nos ofrece un interfaz gráco donde el usuario dene los parámetros, congurandoel tamaño y las características de la población. El GUI está formado por los siguientesformularios: 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 losservicios web, como son: la población, el tipo de datos y el valor máximo y mínimo de lospuertos de entrada y salida, así como tipo y el rango de valores para la función  tnesspara 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 iconojusto 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 consultasEn esta gura se muestra el formulario correspondiente a la introducción de los valoresdel número máximo de subconsultas y la probabilidad permitida para las subconsultasactivas (ASQ)y para las subconsultas informativas (ISQ). Una vez congurados todos los parámetros se genera de forma automática la base dedatos XML con: las subconsultas activas, subconsultas informativas, servicios activos ylos servicios informativos y servicios de datos de entrada/salida (Figura 5).
    • Figura 5.- Modelado3.1. Descomposición de la consulta A través del formulario de la Figura 2 se congura el número de las subconsultas decada tipo así como el número de servicios Web, y los tipos y rangos de los puertos deentrada y salida, así como los valores "tness" para el caso de los servicios web. Cada vezque 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 tiposde cheros XML para los servicios web activos y para la función de correspondencias. Encaso de que en la gura 2 hubiésemos seleccionado únicamente una función tness, noaparecerían las líneas del tness_2 y tness_3 en el archivo activate_web_services.xml. Figura 6.- Aspecto de los cheros XML3.2. Selección de servicios Para la selección de servicios se ha implementado una función de correspondencia conbipuertos: de entrada, salida y valores reales (solo para los SW). Para cada subconsultase genera una lista de servicios web que satisfacen su condición dada por la función decorrespondencia, con lo cual tenemos tantas listas de servicios web como se hayan denidoen el interfaz gráco. La longitud de cada una de estas listas es aleatoria. Es de notarque un servicio informativo siempre irá seguido por un servicio de E/S de datos el cualsatisface 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 unade ellas hay que seleccionar los servicios web compatibles. Si son del tipo A hay quelocalizarlos 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, servicosweb y restricciones) es posible generar nuestro espacio de soluciones, representable por
    • ejemplo a modo de grafo, indicando todas las posibles soluciones a nuestro problema departida. En la gura 7 se muestra a modo de ejemplo y esquemáticamente como quedaríarepresentado 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 serviciosde 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 subconsultas3.4. Optimización de la composición Una vez obtenido el espacio de soluciones, hay que optimizarlas. Para ello hemosdiferenciado 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, sepuede especicar el número de iteraciones, la población y el algoritmo a ejecutar: FMJ2o NSGA-II. Figura 9.- Optimización de la Composición de Servicios Web4. 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 anuestras 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 hemosdesarrollado el algoritmo FMJ2 y hemos adaptado el NSGA-II. En las grácas siguientes semuestra una comparativa en función al número de iteraciones y el tamaño de la poblacióngenerada.
    • Gráca 1.- Comparativa para 2.500 iteraciones y 50 de población Gráca 2.- Comparativa para 7.500 iteraciones y 250 de población Gráca 3.- Comparativa para 15.000 iteraciones y 500 de población Analizando las grácas anteriores podemos armar que para poblaciones pequeñas yun 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 mayorpoblació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 exponencialhasta 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.500iteraciones permaneciendo estable a partir de ese punto.5.2. Optimización multiobjetivo Para la optimización multiobjetivo hemos utilizado exclusivamente la adaptación delalgoritmo genético NSGA-II, proporcionado en jMetal [1]. No se han denido pesos paracada objetivo, por lo que cada uno tendrá la misma importancia. Las grácas obtenidasson 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ónde 150, donde después de 2.500 iteraciones podemos deducir que cuando se optimiza unode los objetivos se penaliza el otro, y viceversa. La mayoría de los tness obtenidos seconcentran 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 de150, donde tras 2.500 iteraciones podemos comprobar que sucede algo similar a la grácabiobjetivo.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 FUTUROS7.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 byMulti-Objective Evolutionary Algorithms [3] hemos abstraído el problema, lo hemosmodelado 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 adaptarloa 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 elespacio 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.Referencias1. 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.