Un enfoque para estimar la calidad de servicios en composición de servicios web

(1)

Universidad Nacional del Centro de la

Provincia de Buenos Aires

Facultad de Ciencias Exactas – UNICEN

Un Enfoque para Estimar la Calidad de Servicios en

Composición de Servicios Web

Trabajo Final de la Carrera de Ingeniería de Sistemas

Alumna

Silva, María José

Director

Dr. Guillermo Rodríguez

(2)

1

Agradecimientos

Quiero agradecer a todas las personas que formaron parte de esta etapa tan importante en mi vida. A mi director Dr. Guillermo Rodríguez por su constante apoyo, por brindarme estímulo y guía absoluta durante este trayecto final de mi carrera.

En especial a mi mamá Mercedes, mi papá Osvaldo y su compañera Stella, mi abuela Isabel, mis hermanos Paz, Román y Brenda quienes sin su amor y apoyo incondicional esto no hubiera sido posible.

A las dos personitas que iluminan mi vida con cada sonrisa y abrazo, mis sobrinos Mateo y Magali. A mi amigo Ezequiel, quien con sus consejos y conocimientos me ayudó a sortear los buenos y malos momentos durante mi carrera.

Por último, y no por ello menos importante a mis amigos de siempre, a los que fui cosechando a lo largo de esta etapa y también a los que perdí durante ella, todos ellos son la familia que la vida me permitió elegir.

(3)

2

Resumen

El crecimiento de Internet, la ubicuidad de las computadoras y la disponibilidad de redes de comunicación de alta velocidad impactaron en el diseño de los sistemas en general, reemplazando el concepto de una computadora personal aislada por el de computadoras distribuidas y conectadas. Este concepto permite a las empresas de software utilizar la Web como medio de comunicación para ofrecer servicios. El término "Servicio Web" se refiere a un componente de software que proporciona una funcionalidad específica, que puede ser consumida a través de internet. El desarrollo de software mediante el ensamblaje de servicios independientes se conoce como paradigma de Computación orientada a Servicios (SOC). Una clave en el paradigma SOC es que los servicios pueden ser prestados por terceros, los cuales sólo exponen interfaces de acceso para el mundo exterior.

En este contexto, el análisis de cuestiones relacionadas con la calidad de servicio (QoS) se vuelve crucial para varias actividades relacionadas con servicios Web, desde el descubrimiento de los servicios, la selección de los mismos, composición y su adaptación en los sistemas. Relevando trabajos en el área, poco se ha encontrado en materia de inferencia o predicción de atributos de calidad cuando no se conocen y se precisan para prever, por ejemplo, si una composición de servicios puede ser viable no sólo en términos funcionales, sino también no funcionales.

En el presente trabajo se propone un enfoque basado en un modelo de regresión lineal para determinar relaciones entre los atributos de calidad que exponen los servicios web y las métricas relativas a las interfaces que exponen los mismos. Dicha relación es de crucial importancia para verificar y/o averiguar los niveles de atributos de calidad que proveen los servicios candidatos a componer, en función de las interfaces de dichos servicios.

(4)

3

Índice general

1. Introducción ... 11

1.1 Motivación ... 11

1.2 Solución Propuesta ... 12

1.3 Estructura de la tesis ... 14

2. Marco Teórico ... 16

2.1 Introducción a Service Oriented Computing ... 16

2.2 Servicio Web ... 17

2.2.1 Descripción de Servicios Web ... 18

2.2.2. Descubrimiento de Servicios Web ... 20

2.3 Composición de servicios Web ... 21

2.4 Atributos de calidad ... 21

2.5 Regresión Lineal ... 22

2.5.1 Regresión Lineal Multivariada ... 22

3. Trabajos Relacionados ... 25

3.1 Measuring Web Service Interfaces ... 25

3.2 Regression model for Quality of Web Services dataset with WEKA ... 26

3.3 Heuristics for QoS-aware Web Service Composition ... 26

3.4 An Approach for QoS-aware Service Composition based on Genetic Algorithms ... 27

3.5 Quality Prediction of Service Compositions through Probabilistic Model Checking ... 27

3.6 Web Service Configuration Under Multiple Quality-of-Service Attributes ... 27

3.7 A QoS-Aware Selection Model for Semantic Web Services ... 28

3.8 AI-based web service composition: a review ... 28

3.9 Detecting WSDL bad practices in code-first Web Services ... 28

3.10 Taming Web Services from the Wild ... 28

3.11 Avoid XML schema wildcards for Web Service interfaces ... 29

3.12 Cuadro Comparativo ... 29

4. Enfoque ... 34

4.1 Obtener métricas de interfaz de servicios web ... 35

4.2 Utilización de SoftAudit ... 36

4.4 Herramienta utilizada para unificar los datos ... 42

4.5 Armar modelo de Regresión Lineal ... 42

4.5.1 Supuestos del modelo de regresión lineal ... 42

4.5.2 Diagnóstico del modelo ... 43

(5)

4

4.6.1 Análisis de colinealidad utilizando Infostat ... 45

4.6.2 Normalidad de la muestra utilizando Infostat ... 45

4.7 Implementación del modelo de Regresión Lineal ... 45

4.7.1 Análisis de colinealidad para el modelo planteado ... 46

4.7.2 Análisis de Homocedasticidad para el modelo planteado ... 52

4.7.3 Configuración utilizada para la Regresión Lineal ... 54

4.8 Observación Importante ... 55

4.9 Problemática Planteada ... 57

4.9.1 Modelo de Regresión Lineal para las métricas propuestas por Sneed ... 57

4.10 Conclusión ... 109

5. Resultados Experimentales ... 111

5.1 Objetivos ... 111

5.2 Conformación del Dataset ... 111

5.3 Cálculo del error por mínimos cuadrados ... 111

5.4 Validación de las hipótesis ... 112

5.4.1 Validación de las hipótesis sobre las métricas de Sneed ... 112

5.4.2 Validación de las hipótesis sobre las métricas de Al-Masri ... 116

6. Conclusiones ... 119

6.1 Ventajas ... 119

6.2 Desventajas ... 121

6.3 Limitaciones ... 121

6.4 Trabajos Futuros ... 121

(6)

5

Índice de figuras

Figura 1.1 - Esquema conceptual de la propuesta ... 13

Figura 2.1 - Arquitectura básica de un Sistema Orientado a Servicios ... 17

Figura 2.2 - Pila de protocolos de Servicios Web ... 18

Figura 2.3 - Infraestructura estándar de un Sistema orientado a servicios ... 18

Figura 2.4 - Ejemplo de descripción de servicio web en WSDL ... 20

Figura 3.1 - Cuadro comparativo de los diferentes trabajos presentados ... 31

Figura 3.2 - Gráfico comparativo entre año de publicación y sitio de la publicación ... 32

Figura 3.3 - Gráfico comparativo entre cantidad de publicaciones en Revista y en Conferencia ... 32

Figura 4.1 - Esquema conceptual del Enfoque ... 34

Figura 4.2 - Archivos WSDL sin individualizar en subcarpetas ... 35

Figura 4.3 - Función make_folders.bat ... 36

Figura 4.4 - Archivos WSDL individualizados en subcarpetas ... 36

Figura 4.5 - Configuración de SoftAudit ... 37

Figura 4.6 - Selección de archivos WSDL ... 37

Figura 4.7 - Imagen de archivos generados como salida de SoftAudit ... 38

Figura 4.8 - Ejemplo archivo wsdl_1.MET ... 40

Figura 4.9 - Código para parsear los archivos ... 41

Figura 4.10 - Modelado de “Full Join” entre dos archivos. Herramienta KNIME ... 42

Figura 4.11 - Tabla de correlación entre variables independientes ... 51

Figura 4.12 - Ejemplo de homocedasticidad para la variable dependiente Response Time ... 53

Figura 4.13 - Ejemplo de homocedasticidad mejorada para la variable dependiente Responde Time ... 53

Figura 4.14 - Infostat. Configuración solapa General ... 54

Figura 4.15 - Infostat. Configuración solapa Diagnóstico ... 55

Figura 4.16 – Matriz de correlación entre variables independientes y variables dependientes realizada con KNIME ... 56

Figura 4.17 - Tabla de correlación entre las variables Number of Object-Points e INTERFACE MODULARITY ... 61

Figura 4.18 - Gráfico de Normalidad para la variable dependiente INTERFACE MODULARITY en relación con la variable independiente Number of Object-Points ... 62

Figura 4.19 - Gráfico de Homocedasticidad para la variable dependiente INTERFACE MODULARITY en relación con la variable independiente Number of Object-Points ... 62

Figura 4.20 - Gráfico de Regresión Lineal para la variable dependiente INTERFACE MODULARITY en relación con la variable independiente Number of Object-Points ... 63

Figura 4.21- Tabla de análisis de Regresión Lineal entre la variable dependiente INTERFACE MODULARITY y la variable independiente Number of Object_Points ... 63

Figura 4.22 - Tabla de correlación entre las variables Number of Arguments e INTERFACE MODULARITY ... 64

Figura 4.23 - Gráfico de Normalidad para la variable dependiente INTERFACE MODULARITY en relación con la variable independiente Number of Arguments ... 64

Figura 4.24 - Gráfico de Homocedasticidad para la variable dependiente INTERFACE MODULARITY en relación con la variable independiente Number of Arguments ... 65

(7)

6

Figura 4.26 - Tabla de análisis de Regresión Lineal para la variable dependiente INTERFACE MODULARITY en relación con la variable independiente Number of

Arguments ... 66 Figura 4.27 - Tabla de correlación entre las variables Number of Results e INTERFACE

MODULARITY ... 67 Figura 4.28 - Gráfico de Normalidad para la variable dependiente INTERFACE

MODULARITY en relación con la variable independiente Number of Results ... 67 Figura 4.29 - Gráfico de Homocedasticidad para la variable dependiente INTERFACE

MODULARITY en relación con la variable independiente Number of Results ... 68 Figura 4.30 - Gráfico de Regresión Lineal para la variable dependiente INTERFACE

MODULARITY en relación con la variable independiente Number of Results ... 68 Figura 4.31 - Tabla de análisis de Regresión Lineal para la variable dependiente

INTERFACE MODULARITY en relación con la variable independiente Number of

Arguments ... 69 Figura 4.32 - Tabla de correlación entre las variables INTERFACE STRUCTURE

COMPLEXITY e INTERFACE MODULARITY ... 70 Figura 4.33 - Gráfico de Normalidad para la variable dependiente INTERFACE

MODULARITY en relación con la variable independiente INTERFACE STRUCTURE

COMPLEXITY ... 70 Figura 4.34 - Gráfico de Homocedasticidad para la variable dependiente INTERFACE

COMPLEXITY ... 71 Figura 4.35 - Gráfico de Regresión Lineal para la variable dependiente INTERFACE

COMPLEXITY ... 71 Figura 4.36 - Tabla de análisis de Regresión Lineal para la variable dependiente

INTERFACE MODULARITY en relación con la variable independiente INTERFACE

STRUCTURE COMPLEXITY ... 72 Figura 4.37 - Tabla de correlación entre las variables DATA FLOW COMPLEXITY e

INTERFACE MODULARITY ... 73 Figura 4.38 - Gráfico de Normalidad para la variable dependiente INTERFACE

MODULARITY en relación con la variable independiente DATA FLOW

COMPLEXITY ... 73 Figura 4.39- Gráfico de Homocedasticidad para la variable dependiente INTERFACE

INTERFACE MODULARITY en relación con la variable independiente DATA FLOW

COMPLEXITY ... 75 Figura 4.42 - Tabla de correlación entre las variables LANGUAGE COMPLEXITY e

INTERFACE MODULARITY ... 76 Figura 4.43 - Gráfico de Normalidad para la variable dependiente INTERFACE

MODULARITY en relación con la variable independiente LANGUAGE

(8)

7

Figura 4.45 - Gráfico de Regresión Lineal para la variable dependiente INTERFACE

MODULARITY en relación con la variable independiente LANGUAGE COMPLEXIT ... 77 Figura 4.46 - Tabla de análisis de Regresión Lineal para la variable dependiente

INTERFACE MODULARITY en relación con la variable independiente LANGUAGE

COMPLEXITY ... 78 Figura 4.47 - Tabla de correlación entre las variables INTERFACE DATA

COMPLEXITY e INTERFACE MODULARITY ... 79 Figura 4.48 - Gráfico de Normalidad para la variable dependiente INTERFACE

MODULARITY en relación con la variable independiente INTERFACE DATA

INTERFACE MODULARITY en relación con la variable independiente INTERFACE

DATA COMPLEXITY ... 81 Figura 4.52 - Tabla de correlación entre las variables INTERFACE DATA

COMPLEXITY e INTERFACE REUSABILITY ... 82 Figura 4.53 - Gráfico de Normalidad para la variable dependiente INTERFACE

REUSABILITY en relación con la variable independiente INTERFACE DATA

INTERFACE REUSABILITY en relación con la variable independiente INTERFACE

DATA COMPLEXITY ... 84 Figura 4.57 - Tabla de correlación entre las variables INTERFACE TESTABILITY e

INTERFACE REUSABILITY ... 85 Figura 4.58 - Gráfico de Normalidad para la variable dependiente INTERFACE

REUSABILITY en relación con la variable independiente INTERFACE TESTABILITY ... 85 Figura 4.59 - Gráfico de Homocedasticidad para la variable dependiente INTERFACE

REUSABILITY en relación con la variable independiente INTERFACE TESTABILITY ... 86 Figura 4.60 - Gráfico de Regresión Lineal para la variable dependiente INTERFACE

REUSABILITY en relación con la variable independiente INTERFACE TESTABILITY ... 86 Figura 4.61 - Tabla de análisis de Regresión Lineal para la variable dependiente

TESTABILITY ... 87 Figura 4.62 - Tabla de correlación entre las variables INTERFACE CONFORMITY e

INTERFACE REUSABILITY ... 88 Figura 4.63 - Gráfico de Normalidad para la variable dependiente INTERFACE

REUSABILITY en relación con la variable independiente INTERFACE

(9)

8

Figura 4.64 - Gráfico de Homocedasticidad para la variable dependiente INTERFACE REUSABILITY en relación con la variable independiente INTERFACE

CONFORMITY ... 89 Figura 4.65 - Gráfico de Regresión Lineal para la variable dependiente INTERFACE

REUSABILITY en relación con la variable independiente INTERFACE

CONFORMITY ... 89 Figura 4.66 - Tabla de análisis de Regresión Lineal para la variable dependiente

CONFORMITY ... 90 Figura 4.67 - Tabla de correlación entre las variables DATA FLOW COMPLEXITY e

INTERFACE CONFORMITY ... 91 Figura 4.68 - Gráfico de Normalidad para la variable dependiente INTERFACE

CONFORMITY en relación con la variable independiente DATA FLOW

INTERFACE CONFORMITY en relación con la variable independiente DATA FLOW

COMPLEXITY ... 93 Figura 4.72 - Tabla de correlación entre las variables INTERFACE DATA FLOW

COMPLEXITY, LANGUAGE COMPLEXITY, INTERFACE STRUCTURE

COMPLEXITY e INTERFACE DATA COMPLEXITY con la variable INTERFACE

MODULARITY ... 94 Figura 4.73 - Gráfico de Normalidad para la variable dependiente INTERFACE

MODULARITY en relación con las variables independientes INTERFACE DATA FLOW COMPLEXITY, LANGUAGE COMPLEXITY, INTERFACE STRUCTURE

COMPLEXITY e INTERFACE DATA COMPLEXITY ... 94 Figura 4.74 - Gráfico de Homocedasticidad para la variable dependiente INTERFACE

REUSABILITY en relación con las variables independientes INTERFACE DATA FLOW COMPLEXITY, LANGUAGE COMPLEXITY, INTERFACE STRUCTURE

COMPLEXITY e INTERFACE DATA COMPLEXITY ... 95 Figura 4.75 - Tabla de análisis de Regresión Lineal para la variable dependiente

INTERFACE MODULARITY en relación con las variables independientes INTERFACE DATA FLOW COMPLEXITY, LANGUAGE COMPLEXITY,

INTERFACE STRUCTURE COMPLEXITY e INTERFACE DATA COMPLEXITY ... 96 Figura 4.76 - Tabla de correlación entre las variables propuestas por Al-Masri ... 99 Figura 4.77 - Tabla de correlación entre las variables Response Time y Latency ... 100 Figura 4.78 - Gráfico de Normalidad para la variable dependiente Response Time en

relación con la variable independiente Latency ... 101 Figura 4.79 - Gráfico de Homocedasticidad para la variable dependiente Response Time

en relación con la variable independiente Latency ... 101 Figura 4.80 - Gráfico de Regresión Lineal para la variable dependiente Response Time

en relación con la variable independiente Latency ... 102 Figura 4.81- Tabla de análisis de Regresión Lineal para la variable dependiente

(10)

9

Figura 4.83 - Gráfico de Normalidad para la variable dependiente Availability en

relación con la variable independiente Successability ... 104 Figura 4.84 - Gráfico de Homocedasticidad para la variable dependiente Availability en

relación con la variable independiente Successability ... 104 Figura 4.85 - Gráfico de Regresión Lineal para la variable dependiente Availability en

relación con la variable independiente Successability ... 105 Figura 4.86 - Tabla de análisis de Regresión Lineal para la variable dependiente

Availability en relación con la variable independiente Successability ... 105 Figura 4.87 - Tabla de correlación entre las variables Best Practices y Reliability ... 106 Figura 4.88- Gráfico de Normalidad para la variable dependiente Reliability en relación

con la variable independiente Best Practices ... 107 Figura 4.89 - Gráfico de Homocedasticidad para la variable dependiente Reliability en

relación con la variable independiente Best Practices ... 107 Figura 4.90 - Gráfico de Regresión Lineal para la variable dependiente Reliability en

relación con la variable independiente Best Practices ... 108 Figura 4.91 - Tabla de análisis de Regresión Lineal para la variable dependiente

Reliability en relación con la variable independiente Best Practices ... 108 Figura 5.1 -Ejemplo del cálculo del error o Factor Compensatorio ... 112 Figura 5.2 - Gráfico de relación entre R2, Ꜫ y las correlaciones para las hipótesis

formuladas en base a las métricas de Sneed ... 115 Figura 5.3- Gráfico de relación entre R2, coeficientes y las correlaciones para las

variables planteadas en la Hipótesis 12 ... 116 Figura 5.4 - Gráfico de relación entre R2, Ꜫ y las correlaciones para las hipótesis

(11)

10

(12)

11

1. Introducción

Los sistemas de software modernos se caracterizan principalmente por su creciente complejidad y tamaño. En este contexto, el paradigma de Computación Orientada a Servicios (SOC en inglés) ha ido ganando territorio en la industria del software. Con SOC, la composición de las piezas de software de acoplamiento flexible, llamados servicios, impulsa la construcción de software. Una clave en el paradigma SOC es que los servicios pueden ser prestados por terceros, los cuales sólo exponen interfaces de acceso para el mundo exterior [1].

Dentro del conjunto de servicios, los servicios Web son componentes de software utilizados a través de Internet que se pueden integrar en aplicaciones distribuidas más complejas [2]. Estas aplicaciones distribuidas basadas en servicios web, conocidas comúnmente como sistemas basados en servicios, dependen de estos terceros para garantizar que sus servicios cumplan con la calidad de servicio (QoS) acordada. Una aplicación de Internet puede invocar varios servicios (un servicio Web en acciones de comercio, por ejemplo, podría invocar un servicio de pago, que luego podría invocar un servicio de autenticación para validarlo). Tal escenario se denomina composición de servicios Web, y se puede especificar de forma estática o dinámica [3].

1.1 Motivación

El análisis de cuestiones relacionadas a QoS se vuelve crucial para varias actividades relacionadas con servicios Web, desde el descubrimiento de los servicios, la selección de los mismos, composición y su adaptación en los sistemas. Por lo tanto, QoS actualmente es tema de investigación de significativa importancia en el campo de los servicios Web [4]. En este sentido, han ido surgiendo diferentes tipos de propuestas y enfoques para diversas actividades relacionadas con la definición y el análisis de calidad de servicio en los servicios Web. Por ejemplo, una cuestión interesante es: ¿qué criterios pueden hacer que un servicio sea de “buena” calidad? La respuesta a esta pregunta requiere la determinación de un marco común de entendimiento sobre la que distintos actores pueden comunicarse efectivamente, sin ambigüedades. Los modelos de calidad son ejemplos de estos marcos y son considerados artefactos de ingeniería que se han propuesto para estructurar y estandarizar los conceptos y definiciones de los factores de calidad en los servicios Web. Sin embargo, como sucede en muchas otras áreas de ingeniería, no existe un modelo único de calidad acordado por la comunidad, sino que co-existen varias propuestas. Estas propuestas pueden diferir en varias cuestiones: tamaño, estructura, terminología, principios subyacentes, etc.

Cualquier servicio Web tiene la característica de presentar interfaces claras que definen su funcionalidad. La interfaz de un servicio Web sirve no sólo como medio de comunicación entre el cliente y el servidor, sino como una especificación de la funcionalidad del mismo. Las descripciones de la interfaz de un servicio Web tienen muchos aspectos, tales como la complejidad y la calidad, que pueden ser medidos [5]. Históricamente, los ingenieros de software han utilizado los catálogos de métricas como una herramienta importante para estimar la calidad de sus artefactos de software.

(13)

12

comprensibilidad y descubrimiento de los servicios descritos. En este contexto, la compresibilidad es la capacidad de una descripción de la interfaz de servicio de ser auto-explicativo, es decir, un ingeniero de software puede razonar con eficacia sobre la funcionalidad de un servicio con sólo mirar la descripción de su interfaz. El descubrimiento, por otro lado, se refiere a la capacidad de un servicio de ser recuperado fácilmente, a partir de un registro o repositorio, sobre la base de una descripción parcial de su funcionalidad, es decir, una consulta. Simultáneamente, en [5] el autor describe un conjunto de métricas para evaluar la complejidad y la calidad de interfaces de servicios. En la actualidad no existen trabajos que permitan estimar la calidad de los Servicios Web a partir de analizar la complejidad, tamaño y calidad de su interfaz. Cabe destacar que en el contexto de este trabajo es de gran importancia estimar los niveles de calidad de los atributos de los Servicios Web candidatos a componer en función de las interfaces de dichos servicios, ya que como la composición puede ser realizada de diferentes formas, es decir combinando diversos servicios, elegir los servicios que mejor calidad tengan, implica una mejor performance como resultado de la composición. Estas mejoras van desde obtener resultados en un periodo de tiempo menor, hasta lograr una mayor confiabilidad del sistema o bien una mejor disponibilidad de los servicios que este provee.

En la siguiente sección se presenta un enfoque basado en estadísticas para determinar relaciones entre los atributos de calidad que exponen los servicios web y las métricas relativas a las interfaces que exponen los mismos.

1.2 Solución Propuesta

En este trabajo final se propone un enfoque que les permita a los desarrolladores de software predecir valores de atributos de calidad, con un determinando nivel de confianza, que deben satisfacer los servicios Web candidatos a formar parte de una composición de servicios. Como no siempre se pueden conocer los niveles de atributos de calidad o verificar que realmente dichos candidatos cumplen con los atributos de calidad que exponen, el enfoque propuesto en este proyecto asistirá a los desarrolladores a estimar dichos niveles de calidad a partir de los valores de las métricas de interfaces propuestas en el catálogo de Sneed. La idea detrás de este trabajo se basa en el empleo de estas métricas como indicadores tempranos para advertir a los desarrolladores de software de los atributos de calidad de los servicios que intervienen un proceso de composición de servicios web. Para resolver el problema de la estimación de niveles de atributos de calidad, este enfoque propone explorar técnicas de regresión lineal multivariada, donde la variable dependiente es el nivel de un atributo de calidad y las variables independientes son cada una de las métricas propuestas en el catálogo de Sneed.

El análisis de la regresión lineal es una técnica estadística utilizada para estudiar la relación entre variables que se adaptan a una amplia variedad de situaciones. En la investigación social, el análisis de regresión se utiliza para predecir un amplio rango de fenómenos, desde medidas económicas hasta diferentes aspectos del comportamiento humano. En el contexto de la investigación de mercados puede utilizarse para determinar en cuál de los diferentes medios puede resultar más eficaz invertir; o para predecir el número de ventas de un determinado producto [7, 8]. Si bien existen trabajos que han utilizado regresión lineal para medir calidad de servicios web [9], aún no se ha trabajado sobre el análisis entre métricas de interfaz de servicios web y los atributos de calidad. En este trabajo se explorará regresión lineal para encontrar una aproximación que permita predecir atributos de calidad de un servicio desconocido, que se acoplara a una aplicación por composición, a partir del análisis de métrica de la interfaz que dicho servicio expone.

(14)

13

Figura 1.1 - Esquema conceptual de la propuesta

En primer lugar, el desarrollador cuenta con una aplicación de software basada en Servicios Web que debe ser extendida para cumplir con determinados requerimientos. En efecto, el diseñador comienza a buscar servicios web disponibles en la Web para de tal forma que los mismos permitan satisfacer dichos requerimientos (1). Una vez obtenida información disponible de los servicios Web, el diseñador, haciendo uso del enfoque propuesto, obtiene y analiza las métricas de interfaz de dichos servicios mediante el software SoftAudit. Este software permite obtener un conjunto de métricas definidas por el catálogo de Sneed [5], y de esta manera se arma un dataset con las métricas obtenidas junto con la información sobre atributos de calidad expuesta por cada uno de los servicios web presentes en el dataset armado.

Luego de tener el dataset pre-procesado, el desarrollador está en condiciones de armar un modelo de regresión lineal multivariada con el objetivo de hallar relaciones entre la calidad de la interfaz de los servicios y los atributos de calidad que estos servicios exponen. Para ello, se debe seguir la metodología propuesta por los modelos existentes de Regresión Lineal.

Por último, el desarrollador será capaz de obtener diferentes modelos de regresión lineal de acuerdo al atributo de calidad requerido en la composición de servicios web. Dichos modelos exponen un conjunto de supuestos que hay que verificar y otro conjunto de métricas de calidad que permiten corroborar la fiabilidad de los modelos. De esta manera, el desarrollador selecciona los servicios web adecuados (2) e inicia el proceso de composición de servicios (3), los cuales no solamente son compatibles desde el punto de vista funcional, sino también, desde el punto de vista de atributos de calidad.

(15)

14

Para el modelado estadístico, se utilizará software Infostat.. Finalmente, como resultado del proyecto final, se obtendrá el enfoque descrito anteriormente, junto con la documentación teórica y técnica del mismo, losresultados obtenidos luego de haber evaluado nuestro enfoque con servicios web existentes, y por último, las posibles extensiones para futuros trabajos.

1.3 Estructura de la tesis

El presente documento se organiza de la siguiente manera: En el capítulo 2 se presenta el marco teórico, en el cual se desea utilizar el enfoque propuesto en este trabajo.

En el capítulo 3 se verán los trabajos relacionados a la utilización de Atributos de Calidad (QA) en Composición de Servicios Web.

(16)

15

(17)

16

2. Marco Teórico

Este capítulo describe los conceptos esenciales para el entendimiento del resto de este trabajo. En particular, la Sección 2.1 explica los conceptos fundamentales sobre la Computación Orientada a Servicios; su materialización con las tecnologías actuales se da en la sección 2.2.

En la sección 2.3 se detallan los conceptos de Atributos de Calidad. Luego en la sección 2.4 se explica la Composición de Servicios Web y por último en la sección 2.5 se describen los conceptos de Regresión Lineal.

2.1 Introducción a Service Oriented Computing

En la actualidad, para enfrentar los tiempos exigentes del mercado y los cambios constantes en los requerimientos, los procesos de desarrollo de software han incrementado su confianza en la reutilización de software [22]. Un paradigma de suma utilidad para el desarrollo de aplicaciones distribuidas, que promueve la reutilización de software de manera desacoplada, es denominado Service Oriented Computing (SOC) [20]. Este paradigma tiene como principal objetivo brindar soporte durante el desarrollo de aplicaciones distribuidas en ambientes heterogéneos. Con SOC, los sistemas distribuidos son construidos componiendo o ensamblando funcionalidad existente, la cual es publicada a través de la red y accedida mediante protocolos específicos. A esta funcionalidad se la denomina servicios [20].

Una aplicación Orientada a Servicios puede ser vista como una aplicación basada en componentes (componentes lógicos de software con una interfaz bien definida que se comunican entre ellos a través de mensajes), la cual es creada a partir de ensamblar dos tipos de componentes: internos, los cuales son embebidos dentro de la aplicación, y externos, los cuales se encuentran estática o dinámicamente vinculados al servicio. Ambos exponen una clara interfaz de sus capacidades funcionales.

Cuando se construye una nueva aplicación, el diseñador de software debe decidir de proveer una implementación para algún componente de la aplicación, o bien, utilizar una implementación ya existente. A esto lo llamaremos tercerizar. En este contexto, tercerizar un componente C significa llenar un agujero dejado por una funcionalidad faltante con una implementación de un servicio existente.

El paradigma SOC, reemplaza el desarrollo de componentes específicos de software con una combinación de distintas actividades: descubrimiento de servicios, selección de servicios e integración de servicios en aplicaciones. La arquitectura básica de un sistema orientado a servicios incluye componentes capaces de:

● Intercambiar mensajes. ● Describir los servicios

● Publicar y descubrir las descripciones de los servicios.

(18)

17

componente solicitante, es aquel que realiza la búsqueda de un servicio en una entidad de descubrimiento de acuerdo a sus necesidades y solicita la ejecución del mismo. Un componente proveedor es responsable de publicar la descripción del servicio que provee en una entidad de descubrimiento, así como aceptar y ejecutar las solicitudes a dichos servicios. Un componente de software puede tanto proveer como solicitar servicios. Una entidad de descubrimiento es un componente en el cual el servicio es publicado y puede ser descubierto, puede ser visto como un registro o directorio de servicios [24]. Por lo tanto, un componente de software definido en este tipo de arquitecturas puede tomar al menos uno de los siguientes roles:

● Solicitante de servicios o Consumidor ● Proveedor de servicios

● Entidad de descubrimiento o Registro

En la Figura 2.1 se muestra la interacción entre los roles descritos. Dicha interacción representa el paradigma denominado “find, bind and execute” (Buscar, ligar y ejecutar), el cual involucra descubrir un servicio publicado por algún proveedor que satisfaga las necesidades del solicitante, ligar las operaciones descritas en el servicio e invocarlo [24]. Un servicio es invocado luego que su descripción ha sido descubierta, con lo cual su descripción debe estar disponible en un directorio de servicios (entidad de descubrimiento), que permita a los proveedores registrar los servicios que proveen y a los solicitantes buscar y localizar éstos.

Figura 2.1 - Arquitectura básica de un Sistema Orientado a Servicios

2.2 Servicio Web

(19)

18

El término "Web Services" se utiliza para referirse a una pila de estándares tecnológicos para los servicios que pueden ser publicados, que se encuentran, y se invocan a través de la Web. A continuación, un "Servicio Web" es un servicio que se ha desarrollado de acuerdo a las normas.

Servicio Web un servicio web es un componente de software que puede ser descubierto e invocado utilizando protocolos Web estándar.

Figura 2.2 - Pila de protocolos de Servicios Web

Básicamente, como se muestra en la Figura 2.2, esta pila comprende cuatro niveles: (1) la comunicación, (2) serialización, (3) la descripción y (4) descubrimiento. Desde el nivel más bajo al más alto, el primer nivel define los protocolos que un proveedor de servicios puede utilizar para enviar y recibir datos. El segundo nivel está a cargo de la serialización de los datos a través de un canal de comunicación.

El siguiente nivel define cómo describir un servicio, sus operaciones y argumentos. Finalmente, el nivel superior especifica cómo publicar y descubrir servicios.

En la Figura 2.3 creamos una instancia del modelo SOC mediante el uso de servicios web. La subsección siguiente presenta la descripción de Servicio Web [25].

Figura 2.3 - Infraestructura estándar de un Sistema orientado a servicios

2.2.1 Descripción de Servicios Web

(20)

19

salida asociados a cada operación, así como los tipos de datos utilizados como parámetros. Dichas operaciones y mensajes se describen en abstracto y luego se ligan a un protocolo de comunicación en particular, como puede ser SOAP o POST sobre HTTP. La especificación de servicios está dividida en seis elementos principales:

Definition: Elemento principal de un documento WSDL. Define el nombre del servicio e incluye

todos los servicios descritos en el documento.

Types: Describe los tipos de datos utilizados. WSDL no está asociado a un sistema de tipificación

específico. Por defecto, se utiliza la especificación W3C XML Schema [21]. Message: Corresponde a mensajes unidireccionales, ya sean de solicitud o de respuesta. Define el nombre del mensaje, además de cero o más elementos denominados Parts, que se refiere a los parámetros de los mensajes, o bien a valores de retorno.

PortType: Estos elementos combinan múltiples elementos de tipo Message, con el fin de formar una

operación, la cual puede ser de solicitud (compuesta por un mensaje de solicitud), de respuesta (compuesta por un mensaje de respuesta) o de solicitud/- respuesta (compuesta por un mensaje de solicitud y uno de respuesta). Un PortType puede incluir una o más operaciones.

Binding: Elemento que describe la especificación de cómo el servicio será implementado cuando se

realiza el envío. Más precisamente, detalla como una operación PortType será transmitida. Se puede realizar el transporte vía HTTP GET, HTTP POST o SOAP.

Service: Define la dirección para invocar el servicio específico. Comúnmente, incluye una URL

(21)

20

Figura 2.4 - Ejemplo de descripción de servicio web en WSDL

2.2.2. Descubrimiento de Servicios Web

(22)

21

común entre el proveedor y el consumidor del servicio. Es responsabilidad del proveedor publicar el servicio en la categoría apropiada. En cambio, el consumidor debe acertar la categoría para descubrir servicios de relevancia para él. Además, no se provee ningún mecanismo de soporte para la selección entre servicios alternativos [22]. Está claro que a medida que crece la cantidad de servicios publicados en un registro UDDI, más complicada se convierte la búsqueda manual del servicio dentro de una categoría.

2.3 Composición de servicios Web

La llegada del paradigma descentralizado trae como resultado desafíos a la composición de los servicios.

En primer lugar, sigue siendo complicado y requiere mucho tiempo para implementar, probar, y depurar la composición de los servicios de bajo acoplamiento en los sistemas orientados a servicios junto con las estrategias y las herramientas actuales.

En segundo lugar, los mecanismos de interoperabilidad son muy necesarios debido a la heterogeneidad de los dispositivos en un entorno descentralizado. Es decir, la composición de servicios debe ser independiente de los lenguajes de programación, proveedores y sistemas operativos, entre otros; En este contexto, la exploración de ontologías parece ser una línea de investigación prometedora para lograr portabilidad e interoperabilidad.

En tercer lugar, la composición de servicios auto-adaptables también debe hacer frente a los dispositivos móviles con recursos y capacidades computacionales limitadas; Por lo tanto, es necesario explorar estrategias adaptables a cambios en la topología dentro del entorno de manera de coordinar la composición de servicios, considerando los patrones de movilidad, vida útil de la batería, tolerancia a fallos y fiabilidad.

En cuarto lugar, es extremadamente desalentador para la composición actual de servicios ser conscientes de los numerosos dispositivos y sus fracasos; como consecuencia, la observabilidad de lo que un servicio proporciona sigue siendo un problema a resolver.

Inferencia de información de intérpretes sobre lo que un servicio puede hacer y lo que puede ofrecer, también requiere más investigación.

La interpretación sintáctica de la información basada en el servicio carece de la fiabilidad para realizar esta función correctamente porque falta el significado de la información subyacente ([12]

Por último, la seguridad, la privacidad y la confianza siguen siendo cuestiones abiertas para permitir acceso de servicio en entornos heterogéneos y descentralizados, ya que los servicios que participan en la composición apenas puede estar al tanto de las fuentes de información con las que realmente interactúan. [26].

En el contexto de este trabajo, el análisis de cuestiones relacionadas a QoS es de vital importancia en el campo de la composición de servicios web, ya que conocer la calidad de los servicios garantiza que se pueda obtener una mejor aplicación al momento de realizar la composición.

2.4 Atributos de calidad

(23)

22

referencia a características que éste debe satisfacer, diferentes a los requerimientos funcionales. Estas características o atributos se conocen con el nombre de atributos de calidad.

Un atributo de calidad es una propiedad de un sistema mediante el cual algunas partes interesadas (stakeholders) han de juzgar la calidad.

Los requerimientos de los atributos de calidad, tales como los relacionados a la performance, security, modifiability, reliability y usability, entre otros, tienen una influencia significativa en la arquitectura de software de un sistema [26].

Gran parte de la vida de una arquitectura de software se gasta en el diseño de sistemas de software para cumplir un conjunto de requerimientos de atributos de calidad del software, en general incluyen scalability, security, performance y reliability. Estos a menudo se llaman de manera informal "-ilities" de una aplicación (aunque, por supuesto, algunos como performance no encajan adecuadamente bajo esta especificación léxica).

Los requerimientos de los atributos de calidad son parte de los requerimientos no funcionales de una aplicación, que captura múltiples facetas de cómo se logran los requerimientos funcionales de una aplicación. Todas las aplicaciones tendrán requerimientos no funcionales que se puedan expresar en términos de requerimientos de atributos de calidad.

Para que tenga sentido, los requerimientos de los atributos de calidad deben especificar sobre cómo se debe conseguir una determinada necesidad [27].

Los desarrolladores de sistemas críticos son responsables de identificar los requerimientos de la aplicación, el desarrollo de software que implementa los requerimientos, y la asignación de recursos adecuados (procesadores y redes de comunicación). No es suficiente con satisfacer los requerimientos meramente funcionales, los sistemas críticos en general deben satisfacer requerimientos tales como security, performance y reliability entre otros [28].

“La calidad del software es el grado en que el software posee una combinación deseada de atributos”. [IEEE Std. 1061]

2.5 Regresión Lineal

El análisis de la regresión lineal es una técnica estadística utilizada para analizar la relación entre variables y se adapta a una variedad de situaciones.

En definitiva, la ecuación de la recta tendrá la siguiente forma:

𝑦 = 𝛽0 + 𝛽1𝑥 + 𝜖

2.5.1 Regresión Lineal Multivariada

Hablamos de un modelo de regresión lineal multivariada cuando tenemos 𝑝 − 1 variables explicativas o independientes de tipo continuo, 𝑥1, . . . , 𝑥𝑝 − 1, relacionadas con una variable respuesta o dependiente y a través del modelo:

𝑦 = 𝛽0 + 𝛽1𝑥1 + 𝛽2𝑥2 + . . . + 𝛽𝑝 − 1𝑥𝑝 − 1 +

Ꜫ

(24)

23

El vector de coeficientes es 𝛽 0 = (𝛽0, 𝛽1, . . . , 𝛽𝑝 − 1) ∈ 𝑅 𝑝 , tal que cada coeficiente 𝛽𝑖

cuantifica el peso que tiene la variable xi explicando la respuesta media de y. En concreto, para un valor xi dado de cierta variable 𝑥𝑖 , si se observa 𝑥𝑖 + 1 en dicho predictor y los mismos valores en los restantes regresores (especificados), entonces la predicción de la respuesta media 𝐸(𝑦) se incrementaría en 𝛽𝑖 .

(25)

24

(26)

25

3. Trabajos Relacionados

En el presente capítulo, se detallarán los trabajos relacionados. En la sección 3.1 se describe el trabajo realizado por H. Sneed sobre “Measuring Web Service Interfaces” y la herramienta que él propone para poder medir la interface de los servicios web. La sección 3.2 se muestra el trabajo de S.Gambhir sobre “Regression model for Quality of Web Services dataset with WEKA”. En la sección 3.3 se verá “Heuristics for QoS-aware Web Service Composition” trabajo realizado por R. Berbner.

En la sección 3.4 se describe “An Approach for QoS-aware Service Composition based on Genetic Algorithms”, trabajo llevado a cabo por G. Canfora. La sección 3.5 muestra el trabajo de S. Gallotti “Quality Prediction of Service Compositions through Probabilistic Model Checking".

En 3.6 se muestra “Web Service Configuration Under Multiple Quality-of-Service Attributes” trabajo de P. Xiong. En la sección 3.7 se ve el trabajo de X. Wang sobre “ QoS-Aware Selection Model for Semantic Web Services”. En 3.8 G. Rodríguez muestra un survey sobre “ QoS-Aware Selection Model for Semantic Web Services”.

En la sección 3.9 C. Mateos muestra “Detecting WSDL bad practices in code-first Web Services”. La sección 3.10 muestra el trabajo realizado por Blake y Nowlan sobre “Taming Web Services from the Wild”. En 3.11 Pasley presenta su trabajo “Avoid XML schema wildcards for Web Service interfaces”.

Finalmente en la sección 3.12 se verá un cuadro comparativo con todos los trabajos mencionados anteriormente. También se verán gráficos que denotan cuando y donde fueron publicados dichos trabajos.

3.1 Measuring Web Service Interfaces

Harry M. Sneed en [5] trabajo sobre métricas en cuanto al aspecto funcional, evaluando las interfaces de los servicios web. El mismo consta de diferentes tipos de métricas, que van desde las métricas comunes como el número de líneas de código y número de declaraciones, a las métricas para medir la complejidad y la calidad de Servicios Web.

Se basó en tres tipos de métricas:

● Service Interface Size se divide en tres grupos:

○ data points, la cual abarca métricas tales como líneas de código, número de declaraciones, numero de variables.

○ object point, define el número de operaciones

○ function points, describe el número de entradas y salidas ○ Number of Arguments / Input Variables.

○ Number of Results / Output Variables

● Service Interface Complexity, se identifican tres tipos de complejidad de software: ○ INTERFACE DATA COMPLEXITY

(27)

26

○ INTERFACE STRUCTURE COMPLEXITY ○ DATA FLOW COMPLEXITY (Elshof Metric) ○ LANGUAGE COMPLEXITY (Halstead Metric)

● Service Interface Quality, define la calidad de la interfaz de un servicio. Este grupo está integrado por las siguientes métricas:

○ INTERFACE MODULARITY ○ INTERFACE REUSABILITY ○ INTERFACE TESTABILITY ○ INTERFACE CONFORMITY

La calidad del servicio, puede ser vista de diferentes maneras: por ejemplo si es integrador de sistemas, la reutilización y modularidad son las características más importantes para el mismo. Todas las métricas descritas se pueden encontrar en la interfaz de un servicio web.

Finalmente, Sneed propone una herramienta SoftAudit, la cual a partir de recibir como entrada una lista de archivos WSDL, permite evaluar la calidad de la interfaz de un servicio web. La misma fue desarrollada para correr en sistemas operativo Windows XP de 32 bits.

Este trabajo fue presentado en la conferencia de IEEE en el año 2010.

3.2 Regression model for Quality of Web Services dataset with WEKA

Shalini Gambhir, Puneet Arora y Jatin Gambhir en [9], armaron un modelo regresión lineal para evaluar la calidad de los servicios web desde el aspecto no funcional, utilizando la herramienta WEKA.

A partir de un dataset que contiene información sobre los siguientes atributos de calidad: Response Time, Availability, Throughput, Successability, Reliability, Compliance, Best Practices, Latency, Documentation; Estos, armaron un modelo de regresión lineal multivariada para poder predecir la calidad de unos atributos en ausencia de otros.

Este trabajo fue publicado en la revista IJECSE en el año 2013.

3.3 Heuristics for QoS-aware Web Service Composition

En [14], trabajo propuesto por Rainer Berbner, Michael Spahn, Nicolas Repp, Oliver Heckmann y Ralf Steinmetz, se analiza la calidad de servicio (QoS) en composición de servicios web.

Su trabajo se basa en el supuesto de que para cada tarea en un conjunto de servicios web con funcionalidades similares, estos tienen diferentes QoS, parámetros y costos, por lo que eso conduce a un problema de optimización al momento de seleccionar los servicios web para cada tarea. Cómo solución propusieron una heurística, que permite obtener el 99% de la solución óptima, tardando menos del 2% del tiempo del algoritmo exacto estándar.

(28)

27

3.4 An Approach for QoS-aware Service Composition based on Genetic

Algorithms

Gerardo Canfora, Massimiliano Di Penta, Raffaele Esposito y Maria Luisa Villani proponen adoptar algoritmos genéticos para optimizar la calidad de servicio (QoS) para obtener mejor tiempo de respuesta o costo total.

Si bien son más lentos que la programación integrada, los algoritmos genéticos representan una opción más escalable y resulta más accesible manejar los atributos genéricos QoS.

Trabajo presentado en GECCO, en el año 2005.

3.5 Quality Prediction of Service Compositions through Probabilistic

Model Checking

Stefano Gallotti, Carlo Ghezzi, Raffaela Mirandola, y Giordano Tamburrelli en [16] apoyan el análisis basado en el modelo de composición de servicios, con un enfoque en la evaluación de los atributos de calidad no funcional, es decir, el rendimiento y la fiabilidad. Desarrollaron una herramienta llamada ATOP, la cual transforma automáticamente un modelo de diseño de composición de servicios en un modelo de análisis, que a su vez alimenta un comprobador probabilístico de modelos para la predicción de la calidad.

Como trabajo futuro proponen sistematizar las observaciones del rendimiento de los atributos en un servicio compuesto. También proponen realizar recuperación del entorno del diseño en el caso que se determina que el comportamiento del sistema es inconsistente respecto del modelo del diseño, para ello se debe volver a calibrar el diseño del modelo, lo cual requiere que los modelos se mantengan con vida en tiempo de ejecución.

Presentado en una conferencia de Springer / LNCS en el año 2008.

3.6 Web Service Configuration Under Multiple Quality-of-Service

Attributes

Cuando un servicio web no cumple con las necesidades del solicitante, los servicios se deben configurar dinámicamente para formar una composición de servicios web.

Como muchas configuraciones proporcionan la misma funcionalidad con diferente calidad de servicio hay que elegir cuál es el más propicio.

Lo que PengCheng Xiong, YuShun Fan, y MengChu Zhou proponen en [17] es formular una configuración de los servicios web mediante las redes de Petri mediante el análisis de la estructura gráfica y las propiedades algebraicas. Este resultado es posteriormente utilizado para formular la optimización de múltiples atributos de QoS.

(29)

28

Trabajo presentado para la revista IEEE TRANSACTIONS ON AUTOMATION SCIENCE AND ENGINEERING, en el año 2009.

3.7 A QoS-Aware Selection Model for Semantic Web Services

Xia Wang, Tomas Vitvar, Mick Kerrigan, y Ioan Toma proponen un enfoque basado en QoS para la selección de servicios web, por presenta un algoritmo justo y sencillo para la evaluación de múltiples métricas de calidad en combinación.

En [18] especifican una ontología de calidad de servicio y su vocabulario utilizando Servicios Web Modelado Ontología (WSMO) para el servicio de anotaciones descripciones con datos QoS. Presentan un mecanismo de selección justo y dinámico, utilizando un algoritmo de normalización óptimo.

Trabajo presentado para la conferencia Springer en el año 2006.

3.8 AI-based web service composition: a review

Guillermo Rodríguez, Álvaro Soria y Marcelo Campo, en [29] proponen varios enfoques contemporáneos que utilizan IA para explorar soluciones alternativas al momento de realizar una composición de servicios web. De esta manera se pueden producir composiciones de servicios web flexibles y adaptables, logrando así una mejor interoperabilidad entre aplicaciones distribuidas y heterogéneas.

Survey presentado en la revista Standard Serif-IETE en el año 2015.

3.9 Detecting WSDL bad practices in code-first Web Services

C. Mateos, M. Crasso, A. Zunino y J. Coscia en [11] encontraron que existe una alta correlación entre las métricas orientadas a objetos tomadas en los servicios de ejecución de código y las ocurrencias de ‘anti-patrones “en sus WSDL Se demuestra que algunas refactorizaciones simples pueden mejorar la calidad de los documentos WSDL.

Los autores recogen un conjunto de datos de proyectos de servicios web a disposición del público, que por sí solo ha sido una valiosa contribución al campo, y analizan estadísticamente las relaciones entre las métricas que fueron tomadas de implementaciones de servicios y métricas tomadas de documentos WSDL correspondientes.

Por lo tanto, estudian las relaciones entre la implementación de métricas del servicio y la exhibición de las interfaces de los servicios de destino en el WSDL.

3.10 Taming Web Services from the Wild

(30)

29

Entonces, los autores proponen un enfoque para tratar con naming tendencies, el cual puede ser incorporado a sistemas de descubrimiento basados en comparaciones sintácticas. Un enfoque completamente sintáctico no puede sustituir en su totalidad la necesidad de descripciones semánticas, sin embargo, ayuda a mejorar la precisión de enfoques semánticos y evita realizar una transformación semántica, en caso de no ser requerida. En resumen, el estudio describe la aplicación del enfoque propuesto extrayendo palabras claves de los elementos que conforman las descripciones de los servicios web y analiza el grado de similitud que existe entre ellas.

Los autores llegan a la conclusión que muchos de los documentos WSDL asociados a servicios web reales y actualmente activos, contienen nombres no representativos, esa mala práctica impacta negativamente sobre la efectividad de recuperación de un servicio en particular.

Este trabajo fue presentado en la revista IEEE Internet Computing en el año 2008.

3.11 Avoid XML schema wildcards for Web Service interfaces

Pasley en [13] presenta un estudio que enumera los efectos negativos que acarrea utilizar los constructores xsd any y xsd: any Atribute, los cuales denomina Wildcards. Estos constructores fueron definidos por la W3C3 _{para ofrecer mayor extensibilidad y permitir a un schema XML}

permanecer invariable cuando cambia el formato de datos que transporta algún mensaje. Algo similar ocurre en el lenguaje java, cuando se utilizan parámetros tipo Object (la clase base de la que el resto de las clases hereda) para soportar diferentes tipos de objetos. La extensibilidad que provee el uso de estos constructores, promueve efectos secundarios poco deseados, tales como, mayor dificultad para comprender las interfaces de los servicios y por ende, mayor complejidad en el proceso de desarrollo de servicios web. Sin embargo, los Wildcards son comúnmente utilizados para asegurar compatibilidad hacia atrás en futuras versiones de las interfaces.

Para solucionar este problema el autor propone una estrategia de administración de versiones para los schemas XML utilizados en servicios web que permite modificar los mismos cuando nuevos requerimientos surgen, al mismo tiempo que se mantiene la compatibilidad hacia atrás, para aquellos servicios que se desarrollen utilizando una versión anterior del schema sigan funcionando normalmente con la nueva versión. De esta forma, se obtiene un schema consistente, bajo control de versiones y de menor complejidad que si se hubiera optado por utilizar el constructor <any>. Estas virtudes, además, permiten minimizar el tiempo empleado por los desarrolladores en su interpretación, reduciendo así, el tiempo de desarrollo de los servicios web.

3.12 Cuadro Comparativo

A continuación en la Figura 3.1 muestra una tabla con los trabajos relacionados y sus características tales como desventajas, año de publicación, si fue realizado para una revista o congreso, si aplica técnicas de IA, los lenguajes de programación utilizados y ambiente para el cual fue desarrollada la herramienta en el caso que la hubiera.

(31)

(32)

31

(33)

32

Figura 3.2 - Gráfico comparativo entre año de publicación y sitio de la publicación

La Figura 3.2 muestra el año de publicación de cada uno de los artículos y si estos fueron publicados en Revista o en Conferencia. Se puede ver que las últimas publicaciones han sido en su mayoría en Revista que en conferencia.

Figura 3.3 - Gráfico comparativo entre cantidad de publicaciones en Revista y en Conferencia

(34)

33

(35)

34

4. Enfoque

En el presente capítulo se plantea el enfoque utilizado para estimar la calidad de servicios en Composición de Servicios Web.

La Figura 4.1 muestra cómo se detalla la metodología a lo largo de este capítulo.

En primer lugar, se tiene un dataset de archivos WSDL que contiene los valores de las métricas de calidad propuesto por Al-Masri (1). Dicho conjunto de archivos es preprocesado para poder ser utilizado posteriormente por la herramienta SoftAudit provista por H. Sneed y de esa forma obtener un dataset con las métricas de las interfaces de los archivos WSDL (2). Una vez que se tienen ambos dataset con sus respectivas métricas por separado, se utiliza la herramienta KNIME para poder fusionar los dataset en uno solo que combine la información de ambos (3). A partir del Full Dataset armado, se procede a utilizar la herramienta Infostat (5) para poder armar ecuaciones Regresión Lineal tomando como variables regresoras las métricas de las interfaces de los servicios web y como variable dependiente las métricas de calidad de los servicios web, y de esa manera poder predecir la calidad de los servicios web a partir de analizar su interfaz.

A continuación se detalla el procedimiento llevado a cabo para poder obtener un modelo de regresión lineal. En la sección 4.1 se describe cómo fueron obtenidas las métricas de interfaz de los servicios web a partir de un conjunto de archivos WSDL, la sección 4.2 describe cómo se mapea el procesamiento de dichos archivos con la herramienta SoftAudit.

En las secciones 4.3 y 4.4 se detalla el código implementado y la herramienta utilizada para poder unificar el dataset con la información de atributos de calidad y el dataset con la información de las métricas de las interfaces de los archivos WSDL respectivamente.

Los pasos a seguir y los conceptos fundamentales del modelo de regresión lineal, se encuentran en la sección 4.5, mientras que en la sección 4.6 se explica el mapeo entre los conceptos del modelo de regresión lineal y el uso de la herramienta Infostat que fue utilizada para poder obtener las ecuaciones. La sección 4.7 muestras como se realizó el análisis de las variables utilizada en el modelo.

Luego en la sección 4.8, se muestra una observación importante en el modelo implementado en un principio, la cual es desencadenante a una nueva problemática planteada en la sección 4.9.

(36)

35

Finalmente en la sección 4.10 se muestran las conclusiones obtenidas.

4.1 Obtener métricas de interfaz de servicios web

Se cuenta con un conjunto de archivos WSDL, el cual contiene la información de los atributos de calidad que satisfacen cuantitativamente cada WSDL.

Dicho dataset fue provisto gentilmente por Al-Masri. Estos atributos son:

● Response Time: tiempo necesario para enviar una solicitud y recibir una respuesta. Medida en Ms.

● Availability: probabilidad de que un sistema esté disponible cuando se lo necesite. Número de invocaciones satisfactorias / Total invocaciones. Medida en %.

● Throughput: cantidad de invocaciones que el sistema puede procesar en un período de tiempo. Se mide en invocaciones/segundo.

● Successability: número de respuestas / número de solicitud de mensajes. Medida en %.

● Reliability: relación entre el número de mensajes de error y el total de mensajes. Medida en %.

● Compliance: grado en el que un documento WSDL sigue la especificación WSDL. Medida en %.

● Best Practices : medida en la que un Servicio Web sigue un perfil básico WS-I. Medida en %.

● Latency): tiempo utilizado por el servidor para procesar una determinada solicitud. Medida en Ms.

● Documentation: mide la documentación, es decir, la descripción de los tags en WSDL. Medida en %.

El dataset fue particionado en: un 75% para “training” y un 25% para “testing” (para más información ver sección 5.2 del capítulo 5).

En primera instancia, todos los archivos, fueron preprocesados de la siguiente manera: Se introdujeron los WSDL en una carpeta (Figura 4.2).

(37)

36

Al ejecutar “make_folders.bat” (código detallado en la Figura 4.3), lo que se logró fue individualizar todos los archivos en subcarpetas para que puedan ser analizados en la etapa posterior utilizando la herramienta SoftAudit (Figura 4.4).

Figura 4.3 - Función make_folders.bat

Figura 4.4 - Archivos WSDL individualizados en subcarpetas

4.2 Utilización de SoftAudit

SofAudit, es la herramienta que fue provista gentilmente por Harry Sneed. La misma fue de vital importancia para poder llevar a cabo este trabajo.

En primer lugar, se utilizó una máquina virtual de Windows XP de 32 bits, para que SoftAudit pueda funcionar.

Una vez que se tuvo la herramienta configurada y funcionando, se pasó a la siguiente etapa, la cual consiste en procesar con SoftAudit los archivos WSDL preprocesados anteriormente.

(38)

37

Figura 4.5 - Configuración de SoftAudit

En la Figura 4.6 se muestra el proceso de selección de los archivos WSDL, para su posterior análisis.

(39)

38

Se debe elegir la opción “Add complete directories”, que permite seleccionar todas las subcarpetas, las cuales contienen cada una un archivo WSDL.

Una vez seleccionados los archivos, se debe definir la carpeta de salida, en donde se van a guardar los resultados obtenidos. Eso se logra a través de la solapa “Ouput directory”.

Por último, presionar “Start Analysis”.

Al finalizar el análisis, para cada WSDL se obtiene como salida un archivo de extensión “.MET” (Figura 4.7).

Figura 4.7 - Imagen de archivos generados como salida de SoftAudit

Cada archivo de salida puede ser leído con un editor de texto.

(40)

(41)

40

(42)

41

Como se observa en la Figura 4.8, cada archivo de salida de SoftAudit de extensión .MET contiene todas las métricas correspondientes al análisis de la interfaz de cada archivo WSDL. Se obtiene un archivo .MET por cada archivo WSDL analizado.

Las métricas que están encuadradas son las que vamos a utilizar para poder predecir la calidad de los servicios web en la siguiente etapa.

La elección de dichas métricas para armar el dataset fue realizada en base al catálogo de métricas propuesto por Sneed [5].

4.3 Incorporar Atributos de calidad

Una vez obtenidas las métricas de interfaz de los servicios web, pasamos a la siguiente etapa que es armar el dataset que una las métricas de interfaz de los servicios web y las métricas de calidad de los mismos.

Se implementó una funcionalidad para poder parsear todos los archivos WSDL y poder extraer las métricas de los atributos de calidad que estos contenían (Figura 4.9).

(43)

42

4.4 Herramienta utilizada para unificar los datos

Para poder unificar los datos, es decir las métricas de Sneed y las métricas de calidad de los archivos WSDL, se utilizó el software KNIME.

KNIME es una plataforma de minería de datos que permite el desarrollo de modelos en un entorno visual. Está construido bajo la plataforma Eclipse.

Dicha herramienta se encarga de hacer un “Full Join” entre ambos archivos.

Figura 4.10 - Modelado de “Full Join” entre dos archivos. Herramienta KNIME

La figura 4.10 muestra cómo se realiza de manera sencilla el Full Join, dado como entrada el dataset que contiene las métricas de Sneed y el dataset con las métricas de Al-Masri. Como salida se obtiene un archivo CSV con la información de ambos dataset en uno solo, producto del Full Join realizado.

De esta manera se pudo armar un dataset el cual cuenta, por un lado con la información de las métricas de las interfaces de los archivos WSDL, y por otro lado con la información de las métricas calidad de cada archivo WSDL.

4.5 Armar modelo de Regresión Lineal

El objetivo de esta etapa es armar un modelo de regresión lineal multivariada, tomando como variables independientes o regresoras a las métricas propuestas por Sneed en su catálogo, y como variables dependientes a las métricas de los atributos de calidad (QA) propuestas por Al-Masri. Como se cuenta con más de una variable dependiente, se va a hallar una ecuación de regresión lineal para cada variable.

4.5.1 Supuestos del modelo de regresión lineal

Para que el modelo sea válido se deben verificar tres supuestos:

(44)

43

Estudia el grado de asociación de dos o más variables. En este caso se utilizará el coeficiente de correlación de Pearson, el cual es una medida de la magnitud de la asociación lineal entre dos variables que no depende de las unidades de medida de las variables originales. Para las variables j-ésima y k-j-ésima se define como:

Donde 𝑆𝑗𝑘 es la covarianza entre la variable j y la variable 𝑘, 𝑆2𝑗 𝑦𝑆2𝑘son las varianzas de las variables 𝑗 𝑦 𝑘 respectivamente.

El coeficiente de correlación muestral representa la covarianza de los valores muestrales estandarizados. Asume valores en el intervalo [−1; 1] y el signo indica la dirección de la asociación (valores negativos se producen cuando la tendencia promedio indica que si un valor en el par observado es más grande que su media, el otro valor es más pequeño que su media).

● Normalidad de la muestra

Indica que los valores de la variable dependiente deben seguir una distribución normal respecto a los valores de la variable independiente.

● Homocedasticidad

Se dice que existe homocedasticidad cuando la varianza de los errores estocásticos de la regresión es la misma para cada observación i (de 1 a n observaciones), es decir:

Donde es un escalar constante para todo 𝑖. Lo que significa que hay una distribución de probabilidad de idéntica amplitud para cada variable aleatoria.

Una vez halladas las ecuaciones de regresión lineal, para cada una de ellas se debe realizar el diagnóstico del modelo.