cenidet Centro Nacional de Investigación y Desarrollo Tecnológico Departamento de Ciencias Computacionales TESIS DE MAESTRÍA EN CIENCIAS EN CIENCIAS DE LA COMPUTACIÓN Banco de Pruebas Orientado a la Calidad o QoS para Apoyar la Selección y Composición de Servicios Web presentada por Oscar Jair Cabrera Bejar Ing. en Sistemas Computacionales por el I. T. de Chilpancingo como requisito para la obtención del grado de: Maestría en Ciencias en Ciencias de la Computación Director de tesis: M.C. Olivia Graciela Fragoso Díaz Co-Director de tesis: Dr. René Santaolaya Salgado Jurado: Dr. Juan C. Rojas Pérez – Presidente M.C. Mario Guillén Rodríguez – Secretario M.C. Reynaldo Alanís Cantú – Vocal M.C. Olivia Graciela Fragoso Díaz – Vocal Suplente Cuernavaca, Morelos, México. 18 de septiembre de 2009
109
Embed
cenidet Oscar Jair... · cenidet Centro Nacional de Investigación y Desarrollo Tecnológico Departamento de Ciencias Computacionales TESIS DE MAESTRÍA EN CIENCIAS EN CIENCIAS
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
cenidet
Centro Nacional de Investigación y Desarrollo Tecnológico
Departamento de Ciencias Computacionales
TESIS DE MAESTRÍA EN CIENCIAS EN CIENCIAS DE LA COMPUTACIÓN
Banco de Pruebas Orientado a la Calidad o QoS para Apoyar la Selección y Composición de Servicios Web
presentada por
Oscar Jair Cabrera Bejar Ing. en Sistemas Computacionales por el I. T. de Chilpancingo
como requisito para la obtención del grado de:
Maestría en Ciencias en Ciencias de la Computación
Director de tesis: M.C. Olivia Graciela Fragoso Díaz
Co-Director de tesis:
Dr. René Santaolaya Salgado
Jurado:
Dr. Juan C. Rojas Pérez – Presidente M.C. Mario Guillén Rodríguez – Secretario M.C. Reynaldo Alanís Cantú – Vocal
Cuernavaca, Morelos, México. 18 de septiembre de 2009
DEDICATORIASDEDICATORIASDEDICATORIASDEDICATORIAS
A Dios:A Dios:A Dios:A Dios: Por darme a una familia maravillosa y llena de salud. Por cuidarme, protegerme y no dejarme caer aún en los caminos más difíciles de mi vida. Por iluminarme en cada una de las etapas de mi vida, darme amor,
sabiduría y sobretodo vida para cumplir con mis metas y objetivos.
A mis padres: A mis padres: A mis padres: A mis padres: Antonio CabreraAntonio CabreraAntonio CabreraAntonio Cabrera y Josefina Bejary Josefina Bejary Josefina Bejary Josefina Bejar Por ser los mejores padres del mundo. Por ser guías clave en todas las etapas de mi vida, sin ustedes todo
esto fuera sólo un sueño. Gracias por todo y en especial por ser mis padres, los AMO.
A mis hermanos: Flor Rubi y AntonioA mis hermanos: Flor Rubi y AntonioA mis hermanos: Flor Rubi y AntonioA mis hermanos: Flor Rubi y Antonio CabreraCabreraCabreraCabrera Por ser los mejores hermanos del mundo, los quiero mucho y cada triunfo obtenido es siempre pensando en
ustedes y para ustedes, los AMO.
A toda mi familia:A toda mi familia:A toda mi familia:A toda mi familia: Porque los triunfos logrados por cada uno de nosotros son triunfos de todos.
A CONACYT por ayudarme económicamente en el desarrollo de esta tesis de maestría. Al Centro Nacional de Investigación y Desarrollo Tecnológico CENIDET, así como a todo el
personal que en el labora, por realizar los procesos escolares que a mi corresponden hasta el termino de la maestría.
A mi director y codirector de tesis: la MC. Olivia G. Fragoso Diaz y el Dr. René Santaolaya
Salgado, por el apoyo brindado en el transcurso de toda la maestría. Cada palabra y consejo fueron tomados en cuenta para poder concluir de la mejor manera este trabajo de tesis. Muchas gracias.
Al comité revisor: M.C. Mario Guillén Rodríguez, Dr. Juan C. Rojas Pérezy al M.C. Reynaldo
Alanís Cantú, por todo el tiempo brindado a la revisión de este trabajo de tesis y por sus valiosas aportaciones para mejorarlo.
Al grupo GESSI de la Universidad Politécnica de Cataluña en España, por aceptarme en una
estancia de investigación muy productiva, ya que todas sus aportaciones y participaciones directas se vieron reflejadas al generar el sistema modelo de esta tesis el cual toma por nombre WeSSQoS. Xavi Franch, Jordi Marco, Marc Oriol, Lidia López; Gracias.
A todos mis A todos mis A todos mis A todos mis amigosamigosamigosamigos
A mis mejores amigos y amigas de toda la vida: Toño, Miguel, Robert, Pepin, Emilio, Raúl,
Patriño, Bladi, Chapo, Carlos, Urbina, Erick, Eder, Rodolfo, Jorge, Alejandro, Diana, Evelin, Alejandra, Laura y Eriko.
A mis amigos de generación: Omar, Israel, Rubi, Oscar, Daniela, Sergio, Maribel, Paco y Julio;
Lo logramos.
A dos amigos con dedicatoria especial, por apoyarme con algunos diseños de mi sistema modelo (WeSSQoS) y por ser amigos y apoyo durante toda la maestría: Alejandro Moreno y Jorge Pacheco.
Resumen Los Servicios Web (WS por su significado en inglés Web Services) se han convertido en
una tecnología altamente utilizada en el desarrollo de sistemas de software. Una de sus
problemáticas más importantes es la selección de los servicios Web más apropiados para
satisfacer los requisitos del sistema. Si se consideran los requisitos no funcionales (NFR
del inglés non-functional requirements), la calidad de servicio de los WS contiene la
información necesaria para analizar dicha satisfacción.
En este trabajo de tesis se genera un banco para pruebas de selección de
servicios Web en dos dominios, el de estadística descriptiva y el de predicción
climatológica. El banco de pruebas proporciona descripciones de calidad en el WSDL de
los servicios Web para que modelos de selección por QoS sean probados y evaluados.
También se describe el sistema WeSSQoS como medio para probar el banco de pruebas
y para la ordenación de WS según su grado de satisfacción de los requisitos no
funcionales, calculable a partir de un conjunto de los QoS de dichos servicios Web, que
pueden declararse en el WSDL o bien calcularse dinámicamente mediante monitorización.
La información acerca de los QoS puede provenir de diversas fuentes (diferentes
repositorios WSDL, diferentes monitores, Bancos,…), para probar el funcionamiento de
WeSSQoS se utiliza el banco de pruebas generado y algunos monitores. La arquitectura
de WeSSQoS permite la coexistencia de diversos algoritmos de ordenación de los WS, si
bien esta tesis se centra en uno de ellos que usa la distancia euclidiana como criterio de
ordenación.
Los resultados que se obtuvieron con las pruebas realizadas fueron todos
satisfactorios, es decir, se obtuvieron los resultados esperados. Con lo cual se puede
decir, que el banco de pruebas y el sistema WeSSQoS no mostraron ningún problema en
su funcionamiento al momento de su interacción la cual está basada en servicios Web.
Este trabajo de tesis se realizó en colaboración con el grupo GESSI de la
Universidad Politécnica de Cataluña en Barcelona. El trabajo fue apoyado por el Dr. Xavi
Franch, Dr. Jordi Marco, Marc Oriol y Lidia López.
Abstract Web services (WS) have become a highly used technology used in the development of
Software systems. One of their most important problems is the selection of Web services
that best satisfy the system requirements. If we consider non-functional requirements
(NFR), quality of service for WS contains the information necessary to analyze such
satisfaction.
In this thesis a bank for testing the selection of Web Services in two domains,
descriptive statistical and climatologic prediction was generated. The bank provides quality
descriptions in the WSDL of the Web services for the QoS selection models to be tested
and evaluated. It also describes the WeSSQoS System as a means for testing the bank
and for Web services sorting according to their degree of satisfaction of nonfunctional
requirements, calculable from a set of QoS of those Web services, which may be declared
in the WSDL itself or dynamically calculated through monitoring.
The information about QoS may come from several sources (different repositories
WSDL, different monitors, banks…), to test the performance of WeSSQoS we used the
bank of test generated and some monitors. The WeSSQoS architecture allows the
coexistence of various sorting algorithms for the Web services, although this thesis
focuses on one that uses the Euclidian distance as sorting criteria.
The results obtained with the test realized were all satisfactory, the expected
results were obtained. The bank and the WeSSQoS system showed no problem while they
were working by interacting through Web services.
This thesis Work was realized in collaboration with the GESSI group of the
Polytechnic University of Cataluña in Barcelona. The work was supported by Dr. Xavi
Franch, Dr. Jordi Marco, Marc Oriol and Lidia López.
II
Tabla de contenido
Tabla de contenido
I
Listado de figuras
III
Listado de tablas
IV
Glosario de términos y siglas
V
Introducción
1
Capítulo 1. ANTECEDENTES
5
1.1 Antecedentes 6 1.2 Planteamiento del problema 7 1.3 Objetivo 7 1.4 Trabajos relacionados 7 1.4.1 Algoritmos de selección de servicios Web con restricciones de QoS End-to-End
8
1.4.2 Cálculo de QoS y seguridad en selección dinámica de servicios Web
9
1.4.3 Modelo de selección con interés en QoS para la semántica de servicios Web
10
1.4.4 Algoritmos de selección de servicios para composición de servicios complejos con múltiples restricciones de QoS
11
1.4.5 Sistemas multiagente para la dinámica de selección de servicios Web
11
1.4.6 Selección de servicios Web manejando calidad 11 1.4.7 Selección de servicios escalables para composición de servicios Web soportando diferentes clases de QoS
12
1.4.8 Un marco y algoritmo de búsqueda de QoS para selección dinámica de servicios Web
12
1.4.9 Tabla comparativa 13 1.5 Producto resultado y beneficios 15
1.6 Alcances y limitaciones
15
Capítulo 2. MARCO TEÓRICO 17
2.1 Servicios Web 18 2.2 Arquitectura de los servicios Web 18 2.3 Estándares de los servicios Web 19 2.3.1 Protocolo de acceso a objetos sencillos, SOAP 19 2.3.2 WSDL (Web Services Description Language) 20 2.3.3 UDDI (Universal Description, Discovery and Integration) 20
III
2.4 Lenguaje de marcado extensible (XML) 21 2.5 Arquitectura orientada a servicios (SOA) 22 2.6 Requisitos funcionales y no funcionales 23 2.7 Banco de pruebas 24 2.8 Atributos de calidad 24 Capítulo 3. BANCO DE PRUEBAS
25
3.1 Descripción de los modelos de atributos de calidad 26 3.1.1 Modelo de calidad McCall (1977) 26 3.1.2 Modelo de calidad Boehm (1978) 29 3.1.3 Estándar ISO/IEC 9126 31 3.2 Aplicabilidad de los modelos de calidad 36 3.3 Atributos orientados a servicios Web 37 3.3.1 Atributos de calidad monitorizables 40 3.4 Selección de atributos de calidad 41 3.5 Dominios del banco de prueba 41 3.6 Extensibilidad del WSDL 43 3.6.1 Estructura y características del WSDL 44 3.7 Creación del banco de pruebas 45 3.8 JUDDI 52 52 Capítulo 4. WeSSQoS 54
4.1 Descripción general de la arquitectura del sistema WeSSQoS 55 4.2 Ejemplo del algoritmo de ordenación: distancia Euclidiana 60 4.3 Descripción del sistema 62 4.4 Escenario para pruebas 64 Capítulo 5. CASOS DE PRUEBA Y RESULTADOS 66
5.1 Casos de prueba 67 5.2 Resultados 76 Capítulo 6. CONCLUSIONES Y TRABAJOS FUTUROS
77
Anexo A. Análisis del modelo de selección basado en QoS
80
Anexo B. Parámetros de entrada del sistema
89
Referencias 94
IV
Listado de figuras
Figura 1. Operaciones y cometidos de los servicios web 19 Figura 2. Funcionamiento de SOAP 19 Figura 3. Localización del WSDL 20 Figura 4. Funcionamiento UDDI 21 Figura 5. Modelo de calidad McCall organizado hacia tres tipos de características de calidad
27
Figura 6. Modelo de calidad McCall ilustrado a través de una jerarquía de 11 factores de calidad (lado izquierdo) relacionados a 23 criterios de calidad (lado derecho).
28
Figura 7. Modelo de calidad McCall (continuación) ilustrado a través de una jerarquía de 11 factores de calidad (lado izquierdo) relacionados a 23 criterios de calidad (lado derecho)
28
Figura 8. Modelo de calidad Boehm 29 Figura 9. ISO 9126, características de calidad y directrices para su uso 31 Figura 10. Modelo de calidad ISO/IEC 9126 33 Figura 11. Características de calidad de los servicios Web 37 Figura 12. Implementación de la base de datos del nodo UDDI privado 52 Figura 13. Esquema conceptual del estándar UDDI versión 2.0 53 Figura 14. Arquitectura general de WeSSQoS 56 Figura 15. Diagrama de secuencia del caso de uso de ordenación de WS 58 Figura 16. Interfaces de los servicios de WeSSQoS 58 Figura 17. Modelo de datos utilizado en la arquitectura de WeSSQoS 59 Figura 18. Algoritmo del módulo de selección 60 Figura 19. Ejemplo de pantalla de resultados de WeSSQoS 63 Figura 20. Escenario para las pruebas de WeSSQo 65 Figura 21. Diagrama de casos de uso para el modelo de selección basado en QoS 85
V
Listado de tablas
Tabla 1. Parámetros de calidad que utilizan 8 Tabla 2. Tabla comparativa 14 Tabla 3. Comparación entre los modelos McCall y Boehm 30 Tabla 4. Comparación entre los modelos de calidad McCall, Boehm e ISO 9126 32 Tabla 5. Métricas estáticas y dinámicas 39 Tabla 6. Métricas de tiempo de respuesta 40 Tabla 7. Atributos de calidad estáticos para servicios Web y rangos 41 Tabla 8. Servicios del dominio estadístico descriptivo 42 Tabla 9. Servicios del dominio predicción climatológica 43 Tabla 10. Resultado de la fase de búsqueda sobre el Anexo A 61 Tabla 11. Tabla de resultados 76 Tabla 12. Prioridad de servicios caso 1 84
VI
Glosario de términos y siglas
a) Agente Es modelado como una entidad separada de clientes y
servidores. Éste puede ser prácticamente implementado
como parte de un cliente, parte de un servidor o un
servicio web independiente.
b) B2B Es la abreviatura comercial de la expresión anglosajona
business to business (comunicaciones de comercio
electrónico) de empresa a empresa, por oposición a las
relaciones de comercio entre empresas y consumidores
(B2C), o las expresiones menos usadas empresas y
gobierno (B2G) o empresas y empleados (B2E).
c) End-to-End Es uno de los principios de diseño del protocolo de control
de transmisiones (TCP) muy usado en la internet así
como en otros protocolos y sistemas distribuidos en
general.
d) Ontología
modelado de servicios Web (WSMO)
Es un modelo conceptual para describir servicios Web
semánticamente y define los cuatro principales aspectos
de la semántica de los servicios Web, es decir,
ontologías, servicios Web, objetivos y mediadores.
e) Optimización
combinatoria Es una rama de optimización y su objetivo es encontrar la
mejor solución posible.
f) Problema Knapsack Es uno de los problemas más estudiados en optimización
combinatoria para muchas aplicaciones de la vida real.
g) Función Objetivo o
lineal Es la formulación matemática de una meta establecida y
por lo tanto su valor final mide la efectividad lograda. La
optimización puede ser minimizando o maximizando la
función objetivo.
VII
h) QoS (Quality of Service) Calidad de servicio se define como el
efecto global de la calidad de funcionamiento de un
servicio que determina el grado de satisfacción de un
usuario. En el contexto de servicios Web los aspectos de
calidad de servicio mayormente considerados son:
disponibilidad, tiempo de respuesta, tiempo de
procesamiento y confiabilidad de resultados [Gerardo04].
i) RTT Round-Trip delay time (RTT). Se aplica en el mundo de
las telecomunicaciones y redes informáticas al tiempo que
tarda un paquete enviado desde un emisor en volver a
este mismo emisor habiendo pasado por el receptor de
destino.
j) Servicio Web Los servicios Web se definen como componentes de
software, los cuales son independientes de la plataforma
e implementación, son aplicaciones auto-contenidas y
modulares que pueden ser: descritas, publicadas,
descubiertas e invocadas [Carlos05].
k) SOA (Service Oriented Architecture) Es un concepto de
arquitectura de software que define la utilización de
servicios para dar soporte a los requerimientos de
software del usuario [Thomas04].
l) SOAP (Simple Object Access Protocol) El Protocolo Simple de
Acceso a Datos es un protocolo basado en XML que se
utiliza para la mensajería de los servicios Web [Thomas04].
m) UDDI (Universal Description Discovery and Integration) UDDI es
un registro diseñado para almacenar de forma
estructurada información sobre empresas y los servicios
Web que éstas ofrecen. A través de UDDI, se puede
publicar y descubrir información de una empresa y de sus
servicios.
VIII
n) UDDI4J UDDI4J es una implementación en Java del protocolo
UDDI. Gracias a UDDI4J, cualquier aplicación escrita en
Java puede interrogar a un registro UDDI para saber qué
servicios Web hay disponibles, obteniendo la descripción
necesaria para poder interactuar con ellos. (Véase: UDDI).
o) UUID (Universally Unique Identifier) Es un identificador de 128
bits usado para referenciar objetos, celdas, interfaces,
registros, etc. Para el caso de registro de servicios Web
se utiliza para hacer referencia a las descripciones
almacenadas en UDDI. (Véase: UDDI).
p) W3C (World Wide Web Consortium) Es la organización
internacional que define normas y reglas para Internet.
q) WSDL (Web Service Description Language) El Lenguaje de
Descripción de Servicios Web es una tecnología utilizada
para definir documentos basados en XML, donde se
incluye toda la información de los servicios, ya sean las
operaciones específicas que ofrece, los parámetros de
dichas operaciones.
r) WSFL (Web Services Flow Language) El Lenguaje de Flujo para
Servicios Web es un lenguaje basado en XML propuesto
por IBM para describir la composición de servicios Web
como parte de la definición de un proceso de negocio.
s) XLANG Es una extensión del WSDL desarrollada por Microsoft
que describe el comportamiento de los servicios Web
como parte de un proceso de negocio.
Introducción
1
Introducción Los Servicios Web (WS) son tecnologías que integran un conjunto de protocolos y
estándares para intercambiar datos entre aplicaciones de software desarrolladas en
distintos lenguajes de programación y ejecutadas en cualquier plataforma. Los estándares
abiertos que utilizan son precisamente los que dotan a éstos de interoperabilidad,
destacando: XML, SOAP, HTTP, WSDL y UDDI [YuT05c].
Los servicios Web se han convertido actualmente en una tecnología de referencia
en la implementación de software de todo tipo. Este éxito se ha traducido en la
proliferación de WS, de manera que para una funcionalidad determinada pueden
encontrase no ya docenas, sino centenares o incluso miles de WS, accesibles
separadamente, residentes en catálogos, etc.
Si bien tal proliferación incrementa las posibilidades de encontrar WS ya existentes
para satisfacer una necesidad dada, al mismo tiempo provoca diversas problemáticas y
entre ellas se destacan precisamente el problema de la selección del WS más apropiado
para un contexto de uso [LiuY04], que se ha convertido en un tema de investigación
esencial en este ámbito. Normalmente este problema se estudia en relación con los
requisitos establecidos por el cliente, es decir, se selecciona el WS que mejor satisface
los requisitos del cliente.
Por lo que se refiere a los requisitos, se considera la distinción clásica entre
requisitos funcionales y requisitos no funcionales [Robertson07]. Por el lado de los requisitos
funcionales, debe validarse que un WS cumple con la funcionalidad propiamente
esperada por el cliente. Por otro lado, los requisitos no funcionales (NFR) se refieren a la
calidad de servicio (QoS) que ofrece el SW, es decir, características propias del WS para
poder ofrecer una cierta funcionalidad: costo de uso, tiempo de respuesta, etc.
Normalmente, la expresión de los NFR en términos de QoS cristaliza en acuerdos
de nivel de servicio (SLA), por lo que finalmente la comprobación de un NFR en un WS
consiste en comprobar que la QoS de dicho WS satisface aquellas cláusulas del SLA que
hacen referencia a los conceptos inherentes a tal NFR.
Introducción
2
Este trabajo de investigación se centra en la ordenación de WS pertenecientes a
un mismo dominio de software según su grado de satisfacción de los NFR establecidos.
Básicamente los puntos a determinar son los siguientes: cuáles son los tipos de NFR
soportados; cómo se expresan dichos NFR; cuál es la medida de satisfacción de un NFR
en un WS dado; cómo se combinan dichas medidas para ordenar los WS según su
adecuación al conjunto de NFR; cómo se obtiene la QoS de un WS; dónde reside dicha
QoS.
En este trabajo de tesis se presenta un banco de pruebas y WeSSQoS (Web
Service Selection based on Quality of Service), un sistema para la selección de WS
basado en QoS, los cuales apoyan la selección y composición de servicios Web.
WeSSQoS propone una arquitectura SOA abierta que acoge en su núcleo uno o más
algoritmos de cómputo de satisfacción de un WS respecto a los NFR. A modo de prueba,
en este trabajo de tesis se utiliza un algoritmo que mide el grado de satisfacción para el
cliente de requerimientos no funcionales en términos de distancia euclidiana.
Los requisitos no funcionales se expresan mediante expresiones formuladas sobre
atributos de calidad cualesquiera. En esta tesis se utilizan 10 atributos provenientes del
modelo de calidad propuesto en [Ameller08]. Los NFR se clasifican entre obligatorios y
opcionales, pudiendo usarse esta información al ordenar los resultados. WeSSQoS está
diseñado para trabajar sobre diversos repositorios de servicios, incluso construidos con
tecnologías diferentes.
Para conocer el comportamiento de los servicios Web respecto a los criterios de
selección, puede usarse o bien la descripción de la QoS que eventualmente forma parte
de la definición del WS en el banco de pruebas o bien puede monitorizarse el
comportamiento del WS, obteniendo la QoS real del WS. En este sentido, se comparte la
visión de [Al-Masri07] que propone que sólo los atributos estáticos (p.e., coste) deberían ser
definidos a priori (atributos utilizados en el banco de pruebas) mientras que los atributos
dinámicos (p.e., disponibilidad) deberían ser obtenidos mediante un sistema de
monitorización.
Organización de la tesis
3
Organización de la tesis El presente documento de tesis está organizado de la siguiente manera:
En el capítulo 1, sección 1.1 se presenta una descripción de los antecedentes de
esta tesis, con el motivo de ubicarse en el contexto de la presente investigación; en la
sección 1.2 se presenta el planteamiento del problema que aborda esta tesis; en la
sección 1.3 se describe el objetivo de esta investigación; en la sección 1.4 se presentan
los trabajos que buscan resolver problemas similares al descrito en esta tesis y se
presentan las diferencias de éstos con respecto a la presente investigación; en la sección
1.5 se presenta el producto resultado de la tesis y los beneficios que se obtienen de su
desarrollo; y finalmente en la sección 1.6, se explican los alcances y limitaciones de esta
investigación.
En el capítulo 2 se presenta el marco teórico que respalda esta tesis. En la sección
2.1 se proporciona una breve descripción del concepto de servicios Web y la
infraestructura que los soporta; en la sección 2.2 se realiza una descripción de la
arquitectura de los servicios Web; en la sección 2.3 se describen los estándares de los
servicios Web; en la sección 2.4 se presenta una descripción del lenguaje XML; en la
sección 2.5 se define y describe la arquitectura orientada a servicios (SOA); en la sección
2.6 se describen las características de los requisitos funcionales y no funcionales; en la
sección 2.7 se realiza una descripción de un banco de pruebas en el contexto de esta
tesis; en la sección 2.8 se realiza una descripción general sobre atributos de calidad;
En el capítulo 3 se describe el desarrollo y especificaciones del banco de pruebas
utilizado en esta tesis. En la sección 3.1 se realiza la descripción de los distintos modelos
de calidad; en la sección 3.2 se describe la aplicabilidad de los modelos de calidad; en la
sección 3.3 se especifican atributos orientados a servicios Web y algunos atributos
monitorizables; en la sección 3.4 se listan los atributos de calidad seleccionados para este
trabajo de tesis; en la sección 3.5 se especifican los dominios y servicios a utilizar; en la
sección 3.6 se describe la extensibilidad y las características que se deben considerar
para editar un WSDL; en la sección 3.7 se describen los pasos que hay que seguir para
crear un banco de pruebas; finalmente en la sección 3.8 se describe la base de datos
utilizada para almacenar la información de los servicios Web.
Organización de la tesis
4
En el capítulo 4 se describe el sistema WeSSQoS. En la sección 4.1 se describe
de forma general la arquitectura del sistema WeSSQoS; en la sección 4.2 se detalla el
funcionamiento del algoritmo de selección con módulos desarrollados en esta tesis; en la
sección 4.3 se realiza la descripción del sistema y finalmente en la sección 4.4 se realiza
una escenario para pruebas del sistema.
En el capítulo 5 se especifican los casos de prueba del sistema WeSSQoS y se
muestra una tabla de resultados. En la sección 5.1 se detallan los casos de prueba y en la
sección 5.2 se muestra una tabla de resultados a los casos de prueba especificados.
En el capítulo 6 de describen las conclusiones y trabajos futuros. Se detallan las
conclusiones obtenidas de la evaluación de este trabajo y finalmente se listan los trabajos
futuros.
Capítulo 1: Antecedentes
5
CAPÍTULO 1: ANTECEDENTES
En este capítulo se realiza la descripción de los antecedentes de este proyecto de tesis, el
planteamiento del problema que se propone resolver y los objetivos que serán base para
solucionar el problema. Así mismo, se describen algunos trabajos relacionados al tema de
tesis y se realiza una tabla comparativa que muestra las diferencias más significativas
entre ellos. También se describe el producto resultado, los beneficios de la investigación y
se detallan los alcances y limitaciones que se plantearon al inicio del proyecto de tesis.
Capítulo 1: Antecedentes
6
1.1 Antecedentes
Esta tesis forma parte de una serie de trabajos realizados en el ámbito de servicios Web
por estudiantes del Centro Nacional de Investigación y Desarrollo Tecnológico (cenidet).
Tres de las tesis que en conjunto forman el antecedente de esta propuesta se describen a
continuación:
• Generación de servicios Web a partir de software legado [Isaac04]
El objetivo general que se planteó en esta tesis es la generación de una
metodología para la implementación de servicios Web a partir de software
legado centralizado, y cuyo enfoque principal es automatizar el proceso de
desarrollo de software. En otras palabras esta metodología estuvo enfocada en
convertir software legado a servicios Web, teniendo como principal objetivo
promover la reutilización de soluciones de software que ya hubieran sido
probadas.
• Sistema de búsqueda y selección de servicios Web [Ismael06]
En esta tesis se analiza el problema de la búsqueda y selección de servicios
Web y se propone un modelo para la solución de dicho problema. El modelo
permite al usuario expresar la funcionalidad requerida de un servicio y
proporciona como resultado, de la búsqueda, la descripción o descripciones de
servicios que proveen la funcionalidad que más se aproxima a la requerida.
Este trabajo utiliza métricas como la precisión, índice de recuperación y nivel
de coincidencia en las búsquedas realizadas usando el modelo propuesto, con
la finalidad de comparar su desempeño con el modelo de búsqueda que
actualmente utilizan los registros públicos de servicios Web.
• Composición de Servicios Web Utilizando Diagramas de Actividad
[Silvana07] En esta tesis se analiza el problema de la composición de servicios y se
propone el uso de diagramas de actividad de UML para el modelado de
procesos que contengan estructuras secuenciales, condicionales e iterativas, y
la generación automática de código en el lenguaje BPEL4WS.
Capítulo 1: Antecedentes
7
1.2 Planteamiento del problema El proceso de selección y composición de servicios Web hoy en día es muy utilizado, con
este proceso se pretende que el o los servicios que se seleccionen sean los más
adecuados para la entidad que desee utilizarlos.
Existen varios modelos que se utilizan para la selección y composición de
servicios, muchos de ellos proponen el empleo de parámetros de calidad o QoS. Sin
embargo, tienen el inconveniente de no contar con pruebas que permitan indicar que los
resultados (conjunto de servicios Web) obtenidos por ese modelo, son los que
proporcionan mejor satisfacción de calidad para cumplir con los requerimientos de quien
hace la petición del servicio.
Por lo anterior, el problema es que no se puede llevar acabo un proceso de
selección y composición de servicios Web basado en parámetros de calidad o QoS. Lo
cual implica, que el usuario tendría que desarrollar el código necesario para completar su
aplicación en lugar de utilizar un servicio Web que ya lo implemente. Esto impactará el
desarrollo del proyecto en tiempo y costo.
1.3 Objetivo El objetivo de este proyecto consiste en establecer un conjunto de servicios Web que
funcionen como banco de pruebas para determinar si los modelos de selección de
servicios que utilizan parámetros de calidad también conocidos como QoS aportan
resultados aceptables. Para esto será necesario seleccionar un conjunto de atributos de
calidad que proporcionen información sobre los servicios Web para propósitos de apoyar
al proceso de selección y composición de los mismos.
1.4 Trabajos relacionados A pesar de la importancia inherente de los atributos de calidad para el descubrimiento y
selección de los servicios web, aún no existe ningún estándar para definir dichos atributos
de calidad. Para solventar este problema, existen múltiples propuestas con el objetivo de
definir un método para incluir la QoS de los servicios. Los métodos propuestos parten de
Capítulo 1: Antecedentes
8
la extensión de estándares actuales, tales como la extensión del WSDL [Ambrogio06],
extensión del UDDI [Chi-Chun08], o el uso de un bróker intermedio para almacenar los
atributos de calidad [D’Mello09].
Una de las problemáticas en cuanto a la definición de la QoS es si la calidad de
servicio prometida por el proveedor del servicio corresponde a la que realmente ofrece el
servicio. En este sentido, [Al-Masri07] propone que sólo los atributos de calidad estáticos (ej.
el costo) deberían estar definidos por el proveedor del servicio mientras que los atributos
dinámicos (ej. tiempo de respuesta, disponibilidad) deberían ser obtenidos a través de un
sistema de monitorización [Zeng07].
1.4.1. Algoritmos de selección de servicios Web con restricciones de QoS End-to-End [YuT05b]
En este artículo se estudian los elementos de QoS end-to-end de servicios compuestos
utilizando un agente que se encarga de seleccionar y coordinar al servicio individual. Se
diseñan algoritmos de selección de servicios usados por agentes para construir el servicio
compuesto óptimo. El enfoque de solución define el mecanismo de agentes para el
manejo de QoS end-to-end en servicios Web compuestos. El objetivo de la función de
utilidad y restricciones utilizadas por los algoritmos propuestos se basan en un amplio
conjunto de parámetros del sistema. Se incluye información del servidor estático (nivel de
servicio), requerimientos QoS del cliente (restricciones QoS), capacidad del servidor
dinámico (beneficios del servicio) y retrasos de comunicación de la red. Además, Los
autores proponen utilizar los atributos de la Tabla 1 que se muestra a continuación:
Tabla 1. Parámetros de calidad que utilizan [YuT05b] Atributos QoS Descripción Valor Tiempo de
respuesta (T)
El intervalo de tiempo que inicia desde que
un usuario hace la petición de un servicio y
termina hasta que recibe la respuesta.
Incluye el tiempo del servicio y el tiempo de
transmisión. Tiempo de servicio: tiempo
para procesar una petición de servicio;
Tiempo de transmisión: tiempo para enviar
una petición al servidor y obtener un
resultado del mismo (Round-trip delay).
El tiempo de servicio es
especificado por el proveedor del
servicio. El tiempo de transmisión
es decidido por la carga de la red.
T = Tsr + Ttr
Tsr: tiempo del servicio;
Ttr: tiempo de transmisión.
Capítulo 1: Antecedentes
9
Costo (C) Incluye el costo del servicio y el costo de
transmisión. Costo del servicio: es el costo
por ejecutar el servicio; costo de
transmisión: es el costo por transmitir el
resultado de un servidor a un solicitante.
El costo del servicio es
especificado por el proveedor del
servicio. El costo de transmisión
es decidido por el operador de
red. C = Csr + Ctr
Csr: costo del servicio;
Ctr: costo de transmisión.
Disponibilidad
del servicio
(A)
La probabilidad en que un servicio está
disponible.
Es calculado a partir de datos
históricos.
A = Ta/Tt
Ta: cantidad de tiempo que un
servicio está disponible;
Tt: tiempo total monitorizado.
Fiabilidad del
servicio (R)
La probabilidad de que una petición sea
correctamente manejada dentro del tiempo
esperado.
Es calculado a partir de datos
históricos.
R = Ns/N
Ns: número de peticiones
respondidas satisfactoriamente;
N: peticiones totales.
1.4.2 Cálculo de QoS y seguridad en selección dinámica de servicios Web [LiuY04]
Con el fin de impulsar o motivar la calidad de selección de servicios Web se desarrolla un
proceso de selección abierto, imparcial y dinámico. Además se propone un marco seguro
para evaluar la QoS de un enorme número de servicios Web. El cálculo imparcial y el
cumplimiento de QoS de servicios Web deben lograr suficiente confianza tanto para los
solicitantes de servicios como para los proveedores. En este artículo se presenta un
modelo de cálculo sobre QoS para selección de servicios web.
En el marco de trabajo que se propone, el modelo de QoS es extensible y la
información de QoS es proporcionada por proveedores, cálculos basados en monitoreo de
ejecución por los usuarios o colectada vía retroalimentación de solicitantes (feedback);
dependiendo de las características de cada criterio de QoS. Para un modelo de QoS
extensible los autores argumentan que no es práctico un modelo de QoS estándar que
pueda ser usado por todos los servicios Web en todos los dominios. Esto es por que QoS
es un concepto amplio que incluye un número de propiedades no funcionales
Capítulo 1: Antecedentes
10
dependientes del contexto, tales como, privacidad, reputación y usabilidad. Además,
cuando se evalúa el QoS de los servicios web se debe tomar en consideración criterios
específicos de dominio.
En cuanto a atributos o parámetros de calidad los autores proponen: criterios de
calidad y criterios relacionados a negocios. Dentro de los criterios de calidad se
consideran 3 criterios de calidad genéricos los cuales pueden ser medidos para servicios
elementales: precio de ejecución, duración de ejecución y reputación. Por el lado de los
criterios relacionados a negocios se mide la usabilidad de tres aspectos: transacción, tasa
de compensación y la tasa por default.
1.4.3. Modelo de selección con interés en QoS para la semántica de servicios Web [Wang06]
Este artículo propone una selección de servicios basada en QoS. Inicialmente se
especifica una ontología de QoS y su vocabulario usando la ontología de modelado de
servicios Web (WSMO) para anotar la descripción de servicios con datos de QoS. Se
continúa por la definición de los atributos de calidad y sus respectivas mediciones junto
con un modelo de selección de QoS.
El escenario de selección de servicios basado en QoS es descrito como sigue. El
usuario proporciona sus requerimientos (incluyendo propiedades no funcionales,
funcionales y de calidad) para el servicio esperado. Éste se forma a partir de un perfil de
requerimientos denotado como SR = (NFR, FR, QR, CR) donde las denotaciones son los
identificadores de no funcional, funcional, calidad y costo.
Los atributos que se manejan en la ontología de este artículo son los siguientes:
Precisión, escalabilidad, fiabilidad, métricas del dominio de aplicación, capacidad, costo,
disponibilidad, robustez, manejo de excepciones, reputación, con relación a la red,
accesibilidad, interoperabilidad, integridad, seguridad (no rechazo, trazabilidad,
encriptación de datos, autenticación, responsabilidad, confidencialidad, autorización),
desempeño (tiempo de respuesta, rendimiento, latencia, tasa por default).
Capítulo 1: Antecedentes
11
1.4.4 Algoritmos de selección de servicios para composición de servicios complejos con múltiples restricciones de QoS [YuT05a]
Una de las promesas de la arquitectura orientada a servicios (SOA) es, que servicios
complejos puedan ser fácilmente compuestos usando servicios individuales de varios
proveedores de servicio. Los servicios individuales pueden ser seleccionados e integrados
de cualquier forma, estáticamente o dinámicamente, basándose en las funcionalidades
del servicio y en los límites de rendimiento. En este artículo se extiende el problema de
selección de servicios a múltiples limitantes QoS. El problema puede ser modelado en dos
formas: el modelo combinatorio y el modelo gráfico (definidos anteriormente por el mismo
autor). Se proponen algoritmos para ambos modelos y se estudia su desempeño por
casos de prueba.
1.4.5. Sistemas multiagente para la dinámica de selección de servicios Web [Maximilien05]
En este artículo se desarrolla un marco multiagente basado en una ontología de QoS y un
nuevo modelo de confianza. La ontología proporciona una base a los proveedores para
anunciar sus ofertas y así los consumidores expresen sus preferencias. Las calificaciones
son esenciales porque dan una base empírica para la selección de los servicios. Las
calificaciones son especificaciones de calidad y se obtienen a través de control
automático o en su caso, por entradas de usuario.
Los agentes así forman un ecosistema en el cual se ayudan unos con otros. Se
evalúa empíricamente el sistema resultante a través de la simulación. Los resultados que
se obtienen muestran que los agentes son capaces de ajustar dinámicamente su
confianza. Finalmente, se selecciona el mejor servicio disponible para las necesidades de
los consumidores.
1.4.6. Selección de servicios Web manejando calidad [J.Hu05]
Para apoyar la rápida y dinámica composición de los servicios Web cuando se conocen
los requerimientos funcionales de los usuarios. Éstos deben ser capaces de ser
localizados y limitados dinámicamente de un constante y gran número de cambios de
proveedores de servicios basado en la calidad del servicio (QoS). A fin de manejar la
calidad en la selección de servicios Web, es necesario hacer una racional y efectiva
Capítulo 1: Antecedentes
12
decisión entre un número de servicios Web basados en criterios de QoS y preferencias de
usuarios. En este artículo se presenta un modelo de decisión de criterios de QoS llamado
DQoS para evaluación de servicios Web, el cual consiste de un modelo de QoS
extensible, modos de decisiones y limitaciones.
1.4.7 Selección de servicios escalables para composición de servicios Web soportando diferentes clases de QoS [Valeria07]
En este artículo se considera a un agente de servicio que ofrece un servicio compuesto
caracterizado por diferentes clases de QoS que implica diversos precios monetarios.
Estas clases de QoS se liquidan sobre la base de algunos acuerdos de nivel de servicio
(SLAs) que el agente negocia con los solicitantes y los proveedores de servicios.
A diferencia de la mayoría de los enfoques actuales que optimizan
independientemente el QoS end-to-end de una sola petición. Se optimiza el QoS
agregando la restricción end-to-end en toda entrada de flujo de peticiones por medio de
un simple problema de programación lineal, que puede ser resuelto de manera eficiente.
Como resultado de ello, el enfoque propuesto es escalable y se presta para una
implementación eficiente.
1.4.8 Un marco y algoritmo de búsqueda de QoS para selección dinámica de servicios Web [Taher05]
La actual arquitectura orientada a servicios (SOA), el concepto de servicios Web y el
registro de servicios carece de mecanismos para manejar las propiedades no funcionales
de los servicios Web. En éste trabajo se propone un marco genérico para un mecanismo
de selección basado en QoS para servicios Web. El marco está representado por dos
modelos, el modelo de datos y el modelo de cálculo. El modelo de datos establece una
ontología para proporcionar una comprensión común del marco, propiedades de QoS y de
semántica.
La información de QoS es de naturaleza dinámica que cambia a lo largo del tiempo
y los consumidores pueden experimentar diferentes valores de QoS del mismo servicio
Web publicado por un proveedor particular. Esto debido a muchos factores tales como la
red y la escalabilidad. Para dar información precisa de QoS y ayudar al consumidor
adaptarse a diferentes condiciones del sistema de proveedores, el marco propuesto
Capítulo 1: Antecedentes
13
soporta múltiple información de QoS por cada servicio Web. Cada uno vinculado a un
modo de QoS. El modo de QoS es la restricción de tiempo; basado sobre el tiempo de
trabajo y la carga de negocio.
Por otro lado, los atributos de calidad en los que se enfoca éste artículo son los
siguientes: escalabilidad, tiempo de respuesta, rendimiento, disponibilidad, accesibilidad y
costo. Estos atributos solo son listados y no se describen por el autor.
1.4.9 Tabla comparativa
Como se ha visto en los puntos anteriores existen diversas propuestas de marcos de
ordenación y/o selección de WS según su QoS. En la Tabla 2 se presentan algunas de
estas propuestas, comparadas según los criterios siguientes:
• Estilo arquitectónico. Arquitectura de la implementación. Se encontraron
arquitecturas basadas en componentes (CBA), arquitecturas orientadas a servicios
(SOA) y una combinación de ambas.
• Atributos. Atributos de calidad utilizados en los sistemas. En algunos casos se usa
un conjunto predeterminado y pequeño de atributos. En otros sistemas, la
arquitectura permite tener atributos arbitrarios, si bien en los trabajos presentados
se utiliza una muestra de los mismos para validar la propuesta. Hay que destacar
que los trabajos tratan indistintamente con atributos estáticos (cuyo valor no
cambia en ejecución) y atributos dinámicos.
• Datos QoS: describe si los valores de los atributos de calidad son declarados en la
definición del servicio o en el caso de ser dinámicos, obtenidos mediante
monitorización.
• Multialgoritmo: Describe si el sistema es capaz de soportar múltiples algoritmos de
selección mediante QoS. Según las descripciones dadas, tan sólo el sistema
QCWS ofrece esta posibilidad, pero no permite añadir algoritmos externos (por no
ser una arquitectura SOA).
Capítulo 1: Antecedentes
14
• Multirepositorio: Describe si el sistema es capaz de obtener los datos de distintos
repositorios y combinarlos para extender la cantidad de servicios y atributos de
calidad a evaluar. El único sistema que presenta esta característica es el de Al-
Masri et al., que obtiene la lista de WS de distintos UDDIs para almacenarlos en el
propio sistema. Sin embargo, no se describe un método para combinar dichos
servicios.
• Prototipo disponible: Indica si existe un prototipo disponible para la comunidad.
Aunque en la mayoría de propuestas se describe un prototipo e incluso algunos
disponen de página web como QCWS, solo se ha encontrado la herramienta
disponible en la propuesta de Al-Masri et al.
Tabla 2. Tabla comparativa
Propuesta Estilo
arquitectónico Atributos Datos QoS
Muti- algoritmo
Multi- repositorio
Prototipo disponible
[Al-Masri07] CBA 4 din. 2 est.
Est. definidos; din. monitorizados
no Si Si
[YuT05a] SOA 4 din. 1
est. Definidos Si, cerrado No No
[YuT05b] CBA 4 din. 1 est. Definidos Si,
cerrado No No
[YuT05c] CBA 4 din. 1 est. Definidos Si,
cerrado No No
[LiuY04] CBA 1 din. 5 est.
Est. definidos; din. monitorizados
No No No
[Taher05] CBA + SOA 5 din. 1 est. Definidos No No No
[Wang06] Sólo algoritmo Config. 1 din. 5
est. Definidos No No No
[Maximilien05] SOA Config. 3 din. Monitorizados No No No
[J.Hu05] SOA 3 din. 2 est. Definidos No No No
[Valeria07] SOA 2 din. 1 est. Definidos No No No
Tesis SOA
totalmente abierta
Múltiples Est.
definidos; din. monitorizados
Si Si Si
Capítulo 1: Antecedentes
15
1.5 Producto resultado y beneficios Existen muchas propuestas para resolver problemas de selección y composición de
servicios Web desde un punto de vista de calidad o QoS. Sin embargo, se carece de
elementos que permitan llevar a cabo pruebas a las soluciones propuestas. Al no existir
algún mecanismo para hacer pruebas a los modelos de selección propuestos, nada
asegura que los servicios seleccionados son los adecuados y esto puede dejar fuera de la
selección a servicios de buena calidad.
Por lo tanto, el producto resultado de esta tesis es la generación de un banco de
pruebas que incluya dos dominios de clasificación de servicios (dominio estadístico
descriptivo y predicción climatológica). Esto para poner a disposición servicios Web que
sirvan de pruebas a los distintos modelos de selección de servicios (ya sea por
funcionalidad o no funcionalidad). Además, se desarrolló un algoritmo de selección de
servicios Web por calidad o QoS y un sistema que permite utilizar los bancos (además de
otros repositorios) para la clasificación de servicios Web.
El beneficio de este proyecto se considera al poner a disposición de investigadores
un conjunto de servicios Web (banco de pruebas) para que puedan probar sus propuestas
o modelos de solución (que utilicen parámetros de calidad) al problema de selección y
composición de servicios Web. Con esto se podrá dar mayor confiabilidad al proceso de
selección en base a QoS. Incluso, los modelos existentes pueden ser mejorados. Con el
sistema que ha tomado el nombre de WeSSQoS el usuario obtiene beneficios tales como
probar distintos algoritmos junto con distintos repositorios.
1.6 Alcances y limitaciones Los alcances establecidos para este proyecto de tesis fueron:
• Determinar los atributos de calidad que se van a utilizar.
Se espera obtener un conjunto de parámetros de calidad entre 2 y 4 que cumplan
con lo señalado anteriormente.
• Generación de servicios Web sin implementación con atributos y valores de
calidad para aplicar el modelo de calidad.
Capítulo 1: Antecedentes
16
Crear mínimo 80 servicios Web en donde sus WSDL contengan información
relacionada a los parámetros de calidad obtenidos del punto anterior. Los servicios
que se implementarán en el banco de pruebas serán no funcionales, es decir, el
cuerpo de cada servicio tendrá una implementación vacía y por tanto, solo se
trabajara con su WSDL.
• Pruebas con los servicios del banco de pruebas.
Realizar pruebas que permitan conocer si es viable esta solución propuesta y claro,
que se arrojen resultados acordes a lo que se espera obtener.
Las limitaciones del proyecto de tesis fueron:
• El conjunto de atributos de calidad seleccionados estará limitado.
El determinar cual es el valor mejor o peor de los atributos de calidad no será objeto
de este estudio.
• La descripción de los servicios va a estar limitada por la capacidad de la
herramienta que genere los archivos WSDL
Puede ser que la herramienta que genere los WSDL de cada servicio este limitada y
de cierta forma, que no permita agregar toda la información sobre los atributos de
calidad con su respectivo valor. Los servicios implementados serán dummys, es
decir, no contendrán ninguna funcionalidad.
• El banco de pruebas solamente se probará en la red local del cenidet y no estará
disponible en internet.
Capítulo 2: Marco teórico
17
CAPÍTULO 2: MARCO TEÓRICO En este capítulo se describen los servicios Web, su arquitectura y sus estándares. Se
describe lo que son los requisitos funcionales y no funcionales, banco de pruebas y
atributos de calidad. Todos los elementos antes mencionados se encuentran fuertemente
ligados con el desarrollo de este trabajo y en conjunto forman el marco teórico que
respalda esta tesis.
Capítulo 2: Marco teórico
18
2.1 Servicios Web [Scotts06] Los servicios Web son módulos de software que realizan tareas o conjuntos de tareas
discretas, a los que se accede y se llama a través de una red, sobre todo la World Wide
Web.
Los servicios Web utilizan SOAP (Simple Object Access Protocol) para la carga del
mensaje XML y utiliza un transporte del tipo HTTP para llevar los mensajes SOAP de un
lado a otro. En realidad, los mensajes SOAP son los documentos XML que se envían
entre el servicio Web y la aplicación que efectúa la llamada.
Los servicios Web y sus clientes se pueden escribir en cualquier lenguaje y se
ejecutan en todas las plataformas. Por ejemplo: un cliente escrito en Delphi que se
ejecuta en Windows puede llamar a un servicio Web escrito en java que se ejecuta en
Linux.
2.2 Arquitectura de los servicios Web [Scotts06] La arquitectura de servicios Web tiene tres propositos: proporciona datos, los solicita y
hace de intermediario. Como proveedor, crea el servicio Web y lo pone a disposición de
los clientes que desean utilizarlo. Realizan la solicitud las aplicaciones cliente que
consumen el servicio Web. El intermediario, como un registro de servicio, permite
interaccionar a la aplicación cliente y al proveedor.
Estos tres cometidos interactúan por medio de las operaciones de publicación,
búsqueda y enlace. El proveedor utiliza la interfaz de publicación del intermediario para
comunicarle la existencia del servidor Web, con el fin de ponerlo a disposición de los
clientes. La información publicada describe el servicio e indica donde se encuentra. La
aplicación que hace la solicitud consulta al intermediario para que busque los servicios
Web publicados. Con la información obtenida del intermediario, la aplicación cliente puede
enlazarse al servicio Web (llamarlo). En la Figura 1 se resume la forma en que interactúan
los tres elementos.
Capítulo 2: Marco teórico
19
Figura 1. Operaciones y cometidos de los servicios web
2.3 Estándares de los servicios Web [Scotts06] Las normas en las que se basa el desarrollo de servicios web son tecnologías en proceso
de evolución. Las principales son SOAP (Simple Access Protocol, Protocolo de acceso a
objetos sencillos), WSDL (Web Services Description Language, Lenguaje de descripción
de servicios web) y UDDI (Universal Description, Discovery, and Integration, Descripción,
detección e integración universales).
2.3.1 Protocolo de acceso a objetos sencillos, SOAP
SOAP es un protocolo de mensajes independiente del transporte. Los mensajes SOAP
son documentos XML. SOAP utiliza mensajes unidireccionales, aunque es posible
combinar mensajes en secuencias de solicitud y respuesta. La especificación SOAP
define el formato del mensaje XML, pero no su contenido ni la forma en que se envía. No
obstante, SOAP especifica la forma en que los mensajes SOAP se encaminan por medio
de HTTP. En la Figura 2 se muestra el funcionamiento de SOAP.
Figura 2. Funcionamiento de SOAP
Internet Consumidor
del servicio
UDDI Publicación del servicio
Proveedor
del servicio
Servidor Web
Consulta
del
servicio
Retorno del contrato
del servicio
Invocar al
servicio de
acuerdo al
contrato
Solicitud
por
servidor
Web
Solicitud
por
proveedor
del servicio
Capítulo 2: Marco teórico
20
Todos los documentos SOAP tienen un elemento raíz <Envelope>. El elemento
raíz es el primero de un documento XML, y contiene a los demás elementos del
documento. Este “envelope” consta de dos partes: la cabecera (header) y el cuerpo
(body). La cabecera contiene los datos de encaminado o contexto y puede estar vacía. El
cuerpo contiene el mensaje propiamente dicho. También puede estar vacío.
2.3.2 WSDL (Web Services Description Language; lenguaje de descripción de servicios Web)
Los servicios web sólo resultan útiles si otras aplicaciones pueden reconocer qué hacen y
la forma de llamarlos. Los desarrolladores deben estar suficientemente informados sobre
un servicio web para poder escribir un programa cliente que lo llame. WSDL es un
lenguaje basado en XML que se utiliza para definir servicios web y describe la forma de
acceder a ellos. Concretamente, describe los contratos de datos y mensajes que ofrece
un servicio web. Los desarrolladores deben examinar el documento WSDL de los
servicios web para averiguar qué métodos hay disponibles y cómo se realizan las
llamadas con los parámetros adecuados, ver Figura 3.
Figura 3. Localización del WSDL
2.3.3 UDDI (por sus siglas en inglés Universal Description, Discovery and Integration)
UDDI es una norma en proceso de evolución, que trata sobre la descripción, la
publicación y la localización de los servicios web que ofrecen las empresas. Se trata de
una especificación para el registro distribuido de información sobre servicios web. Cuando
se ha desarrollado un servicio web y se ha creado un documento WSDL que lo describe,
es necesario que exista una forma de proporcionar la información WSDL a los usuarios
Capítulo 2: Marco teórico
21
del servicio web. Cuando un servicio web se publica en un registro UDDI, los posibles
usuarios pueden buscar e informarse de la existencia de los servicios web, ver Figura 4.
El contenido de un registro UDDI se puede comparar con las guías telefónicas. En
las “páginas blancas” del registro figuran datos como el nombre, la dirección y el número
de teléfono de la empresa que ofrece los servicios web. Las “páginas amarillas” identifican
el tipo de negocio y lo clasifican por sectores de actividad. Las “páginas verdes”
proporcionan datos sobre los servicios web que ofrece la empresa.
Figura 4. Funcionamiento UDDI
2.4 Lenguaje de marcado extensible (XML) [W3C06] El lenguaje de marcado extensible (XML) fue desarrollado por un grupo de trabajo
formado bajo el auspicio del W3C en 1996 y desde entonces ha tenido un desarrollo
exponencial. Surge como un lenguaje de marcado para complementar a HTML. Tomando
como punto de partida al lenguaje SGML (Standard Generalized Markup Language), pero
simplificándolo para poder trabajar en la Web, se creó XML y sólo 2 años después, en
febrero de 1998, fue adoptado como recomendación por el W3C.
“XML es un lenguaje extensible de etiquetas que juega un papel fundamental en
el intercambio de datos. Es muy similar a HTML, pero su función principal es describir
datos y no mostrarlos como es el caso de HTML. XML sirve para estructurar, almacenar e
intercambiar información. Es un formato que permite la lectura de datos a través de
diferentes aplicaciones.
Capítulo 2: Marco teórico
22
Las tecnologías XML son un conjunto de módulos que ofrecen servicios útiles a las
demandas más frecuentes por parte de los usuarios. Entre las tecnologías XML
disponibles se pueden destacar: XSL (Extensible Stylesheet Language), XPath (XML Path
2.5 Arquitectura orientada a servicios (SOA) [Wiki09a] La Arquitectura Orientada a Servicios (SOA en inglés Service Oriented Architecture), es
un concepto de arquitectura de software que define la utilización de servicios para dar
soporte a los requisitos del negocio.
Permite la creación de sistemas altamente escalables que reflejan el negocio de la
organización, a su vez brinda una forma estándar de exposición e invocación de servicios
(comúnmente pero no exclusivamente servicios web), lo cual facilita la interacción entre
diferentes sistemas propios o de terceros. SOA define las siguientes capas de software:
• Aplicaciones básicas - Sistemas desarrollados bajo cualquier arquitectura o
tecnología, geográficamente dispersos y bajo cualquier figura de propiedad;
• De exposición de funcionalidades - Donde las funcionalidades de la capa
de aplicación son expuestas en forma de servicios Web;
• De integración de servicios - Facilitan el intercambio de datos entre
elementos de la capa de aplicación orientada a procesos empresariales
internos o en colaboración;
• De composición de procesos - Que define el proceso en términos del
negocio y sus necesidades, y que varía en función del negocio;
• De entrega - donde los servicios son desplegados a los usuarios finales.
SOA proporciona una metodología y un marco de trabajo para documentar las
capacidades de negocio y puede dar soporte a las actividades de integración y
consolidación.
Capítulo 2: Marco teórico
23
La metodología de modelado y diseño para aplicaciones SOA se conoce como
análisis y diseño orientado a servicios. La arquitectura orientada a servicios es tanto un
marco de trabajo para el desarrollo de software como un marco de trabajo de
implementación. Para que un proyecto SOA tenga éxito los desarrolladores de software
deben orientarse ellos mismos a esta mentalidad de crear servicios comunes que son
orquestados por clientes o middleware para implementar los procesos de negocio. El
desarrollo de sistemas usando SOA requiere un compromiso con este modelo en términos
de planificación, herramientas e infraestructura.
Cuando la mayoría de la gente habla de una arquitectura orientada a servicios
están hablando de un juego de servicios residentes en Internet o en una intranet, usando
servicios web. Existen diversos estándares relacionados a los servicios web. Incluyen los
siguientes:
• XML
• HTTP
• SOAP
• WSDL
• UDDI
Hay que considerar, sin embargo, que un sistema SOA no necesariamente
necesita utilizar estos estándares para ser "orientado a servicios" pero es altamente
recomendable su uso.
2.6 Requisitos funcionales y no funcionales Un requisito funcional, en la ingeniería de sistemas y la ingeniería de software, define el
comportamiento interno del software, es decir, comportamientos y funcionalidades
específicas que muestran cómo los casos de uso serán llevados a la práctica. Son
complementados por los requisitos no funcionales, que se enfocan en cambio en el diseño
o la implementación, con lo cual se especifican criterios que pueden usarse para juzgar la
operación de un sistema [ISO986].
Capítulo 2: Marco teórico
24
2.7 Banco de pruebas Un banco de pruebas para fines de esta tesis, es un contenedor donde se almacenan
servicios Web con implementación no funcional, es decir, solo será de importancia el
WSDL de cada servicio. Todo WS (servicio Web) en el banco de pruebas tendrá una
extensión en su descripción, la cuál corresponderá a la descripción de parámetros de
calidad. Este banco de pruebas servirá como soporte para las distintas propuestas de
solución hacia la selección y composición de servicios Web, es decir, servirá como prueba
para los modelos de selección de servicios basados en QoS, de tal forma que se pueda
verificar si los resultados que arrojan estos modelos son aceptables.
2.8 Atributos de calidad [Maria06] Si sólo la funcionalidad de un sistema de software fuese importante a la hora de hacer su
diseño, cualquier sistema monolítico podría servir. Sin embargo la realidad es otra.
Muchos otros atributos de calidad deben tenerse en cuenta para determinar la estructura
y el comportamiento que tendría el sistema. Hacer un adecuado balance entre la
mantenibilidad, la interoperabilidad, la portabilidad, el rendimiento, la seguridad, la
disponibilidad y la reusabilidad, entre otros atributos, es esencial para obtener un sistema
que cumpla las expectativas de las distintas partes interesadas.
Esto es algo más fácil de decir que de llevar a la práctica debido a que cualquier
cambio en la arquitectura a modo de mejorar un atributo, en general estará afectando
negativamente otro atributo. Como si esto no fuese poco, el diseño de una arquitectura
que tenga en cuenta los atributos deseados, sólo permitirá que el sistema resultante tenga
estas características, pero no lo garantiza.
Se puede clasificar los atributos de calidad del software en dos grandes grupos:
aquellos que pueden comprobarse durante la ejecución del software y aquellos que no
pueden comprobarse durante la ejecución. Dentro del primer grupo se encuentra el
desempeño, seguridad, disponibilidad, funcionalidad y usabilidad. Dentro de los
segundos, y no menos importantes, están la modificabilidad, portabilidad, reusabilidad,
integrabilidad y verificabilidad.
Capítulo 3: Banco de pruebas
25
CAPÍTULO 3: BANCO DE PRUEBAS
En este capítulo se describen tres modelos de atributos de calidad: modelo de McCall,
modelo de calidad Boehm y estándar ISO/IEC 9126. También se describen algunos
atributos de calidad estáticos y dinámicos, los cuales se utilizaron en la implementación
del banco de pruebas. Se especifican los dominios de aplicación a los que corresponden
los servicios Web que se crearon para poblar el banco de pruebas y se describe lo que
son los archivos WSDL necesarios para integrar los atributos de calidad o QoS en la
descripción de los servicios Web. La última sección del capítulo corresponde al proceso
de creación del banco de pruebas y se describe la utilización de JUDDI que se utilizó para
registrar la información de los servicios Web del banco.
Capítulo 3: Banco de pruebas
26
3.1 Descripción de los modelos de atributos de calidad Con el objeto de identificar atributos de calidad se describen tres de los modelos más
importantes: ISO/IEC 9126, Bohem y McCall. Cada modelo tiene distintos atributos de
calidad y forma de representarlos o clasificarlos. La calidad debe ser definida como la
conformidad a los requisitos. En consecuencia, el incumplimiento detectado es la falta de
calidad [Patrik05].
3.1.1 Modelo de calidad McCall (1977)
Uno de los modelos con mucho renombre hoy en día es el modelo de calidad presentado
por Jim McCall (también conocido como el modelo General Electrics de 1977). Éste
modelo se origina en los Estados Unidos para la fuerza aérea US. Promovido dentro del
departamento de defensa y está destinado principalmente para los desarrolladores de
sistemas y los procesos de desarrollo de sistemas.
El modelo de calidad McCall intenta reducir la brecha entre usuarios y
desarrolladores, centrándose sobre un número de factores de calidad de software que
refleja tanto las vistas de usuarios como las prioridades de los desarrolladores.
El modelo de calidad McCall que se muestra en la Figura 5 tiene tres grandes
perspectivas para la definición e identificación de la calidad de un producto de software:
revisión del producto (capacidad de sufrir cambios), transición del producto (la capacidad
de adaptación a nuevos entornos) y las operaciones del producto (características de su
funcionamiento).
Revisión del producto incluye mantenimiento (esfuerzo necesario para localizar y
arreglar una falla en el programa dentro de su entorno operativo), Flexibilidad (facilidad de
hacer cambios requeridos por cambios en el entorno operativo), pruebas (facilidad de
probar el programa a fin de garantizar que esté libre de errores y cumple su
especificación).
Transición del producto tiene que ver con la portabilidad (el esfuerzo necesario
para transferir un programa desde un entorno a otro), reutilización (la facilidad de
reutilización del software en un contexto diferente) y la interoperabilidad (el esfuerzo
necesario para acoplar el sistema a otro sistema).
Capítulo 3: Banco de pruebas
27
La calidad de las operaciones del producto depende de la corrección (la medida en
que un programa cumple con su especificación), fiabilidad (la capacidad de los sistemas
de no fallar), eficiencia (categorizada dentro de la eficiencia de ejecución y eficiencia de
mantenimiento y generalmente significa el uso de recursos. Ejemplo: tiempo de
procesamiento y almacenamiento), integridad (protección del programa contra accesos no
autorizados), usabilidad (la facilidad del software).
Figura 5. Modelo de calidad McCall organizado hacia tres tipos de características de calidad El modelo además detalla dos tipos de características de calidad en una jerarquía
de 11 factores y 23 criterios, representados en las Figuras 6 y 7:
• 11 factores (para especificar): describen la vista externa del software, tal como se
ve por el usuario.
• 23 criterios de calidad (para construir): describen la vista interna del software,
como se ha visto por el desarrollador.
Los factores de calidad describen diferentes tipos de características del
comportamiento de un sistema y los criterios de calidad son atributos para uno o más
Figura 6. Modelo de calidad McCall ilustrado a través de una jerarquía de 11 factores de calidad (lado izquierdo) relacionados a 23 criterios de calidad (lado derecho)
Figura 7. Modelo de calidad McCall (continuación) ilustrado a través de una jerarquía de 11
factores de calidad (lado izquierdo) relacionados a 23 criterios de calidad (lado derecho)
Fiabilidad
Trazabilidad o Rastreabilidad
Consistencia
Precisión
Tolerancia a fallos
Eficiencia en ejecución
Eficiencia en almacenamiento
Control de acceso
Comunicatividad
Correctitud
Eficiencia
Integridad
Usabilidad
Completitud
Operatividad
Auditoria de acceso
Entrenamiento
Simplicidad
Concisidad
Instrumentación
Auto-descripción
Expansibilidad
Generalidad
Modularidad
Independencia del SO
Independencia de la máquina
Interoperabilidad en comunicación
Interoperabilidad en datos
Facilidad de prueba
Mantenibilidad
Reusabilidad
Portabilidad
Flexibilidad
Interoperabilidad
Capítulo 3: Banco de pruebas
29
3.1.2 Modelo de calidad Boehm (1978)
El modelo de Boehm mostrado en la Figura 8 es similar al modelo de calidad de McCall
en el sentido de que también presenta un modelo de calidad jerárquico estructurado
entorno a características de alto nivel, características de nivel intermedio y características
primitivas. Cada una de las cuales contribuye al nivel de calidad global.
Las características de alto nivel son usadas para evaluación de calidad de
software de utilidad general. Dentro de este nivel se encuentran tres cuestiones sobre:
utilidad (eficiente, fiable, fácil), mantenibilidad (modificaciones y pruebas), portabilidad
(ambiente). Las características del nivel intermedio representan 7 factores de calidad que
juntos representan la calidad esperada de un sistema de software. Las características
primitivas (el nivel más bajo de la estructura jerárquica del modelo) proporcionan el
fundamento para definir métricas de calidad.
Figura 8. Modelo de calidad Boehm
Portabilidad Independencia de
dispositivo
Autocontenible
Precisión
Completitud
Robustez/Integridad
Consistencia
Contabilidad
Eficiencia de dispositivo
Accesibilidad
Comunicatividad
Autodescriptividad
Legibilidad
Fiabilidad
Utilidad
Utilidad general
Mantenibilidad
Concisidad
Eficiencia
Estructurable
Aumentabilidad
Ingeniería humana
Entendibilidad
Modificabilidad
Testabilidad
Capítulo 3: Banco de pruebas
30
Aunque los modelos de McCall y Boehm pueden parecer muy similares, la
diferencia es que el modelo de McCall se centra principalmente sobre la medición precisa
de las características de alto nivel. Considerando que el modelo de calidad de Boehm
está basado sobre una amplia gamma de características con un extendido y detallado
foco central que es la mantenibilidad. La Tabla 3 muestra una comparativa por factor de
calidad de los dos modelos según [Patrik05].
Tabla 3. Comparación entre los modelos McCall y Boehm Criterios/Metas McCall, 1977 Boehm, 1978
4.3 Descripción del sistema Se ha desarrollado una aplicación Web que implementa al sistema WeSSQoS, accesible
en la url http://appserv.lsi.upc.es/wessqos/, totalmente operativa.
Para el desarrollo de esta herramienta, se ha escogido el lenguaje de
programación Java J2EE. Sobre éste, existe un amplio conjunto de motores de WS, entre
ellos destacan Apache Axis, Apache Axis2 y Glassfish. Para la implementación de los
servicios que se utilizan en este trabajo se seleccionó Apache Axis2. No obstante, para la
fase de pruebas y con el objetivo de demostrar la independencia tecnológica del sistema
WeSSQoS, se desarrolló un conjunto de WS a evaluar usando Glassfish como
contenedor.
Los servicios colocados en QoSRepositoryProxy requieren, además, de un
espacio para almacenar los atributos de calidad. En esta herramienta, tanto los
repositorios estáticos como los dinámicos almacenan la información necesaria en un
SGBD MySQL. No obstante, se debe tener en cuenta que cada QoSRepostioryProxy
tiene su propia base de datos y que cada implementación puede tener el esquema
conceptual y SGBD que más se ajuste a sus funcionalidades.
La interfaz del sistema consta de tres secciones: Repositories, Stakeholder
Requirements y Results. Estos se describen a continuación:
• Repositories: es la sección donde se introduce el dominio sobre el que se quiere
realizar la búsqueda y los repositorios donde consultar la información. El sistema
permite utilizar tanto dominios y repositorios definidos en nuestra herramienta
como otros externos. En el caso de un dominio externo se introducirá el nombre
que lo identifica en los repositorios. Por otro lado los repositorios se identifican
mediante su endpoint. Los endpoints se visualizan en una tabla al final de la
sección, que permite agregar/borrar. Cabe resaltar que el orden en que se añaden
los repositorios se utiliza como orden de prioridad para la obtención de la
información de un WS del que hay información en más de un repositorio.
• Stakeholder Requirements: es la sección donde el usuario de la herramienta
introduce los NFR cuya satisfacción se comprueba en los WS de los repositorios
identificados en la sección de Repositories. Estos NFR se establecen sobre
Capítulo 4: WeSSQoS
63
atributos de calidad que pueden ser: los atributos que proporciona el propio
sistema WeSSQoS o bien atributos propios del usuario. Obviamente, es
responsabilidad del usuario seleccionar atributos cuya descripción o
monitorización sea cubierta por los repositorios que se han elegido en la sección
Repositories. Por cada atributo seleccionado, se debe introducir el valor requerido,
especificar si se desea maximizar o minimizar y finalmente especificar si es o no
obligatorio a la hora de seleccionar algún servicio (tal y como se describió en el
punto 4.1).
• Results: es la sección donde se muestra el ranking ordenado de los WS de los
repositorios tras aplicar el algoritmo elegido (actualmente, el de distancia
euclidiana) según su QoS. Los WS pueden ordenarse por dos criterios:
considerando sólo la distancia de su QoS respecto los NFR, o bien considerando
el número de NFR obligatorios cumplidos y, en caso de empate, distancia respecto
NFR. La sección permite también obtener algunas gráficas, visualizar los detalles
de los WS, y refinar los NFR para depurar la búsqueda. Por ejemplo, en la Figura
19 se puede observar el resultado de la ordenación de servicios de un repositorio
con 3 requisitos obligatorios en su búsqueda.
Figura 19. Ejemplo de pantalla de resultados de WeSSQoS
Capítulo 4: WeSSQoS
64
4.4 Escenario para Pruebas Para poder probar WeSSQoS, se ha diseñado un escenario para ejecutar los casos de
prueba descritos en el capítulo 5. Este escenario también está disponible en la página
web de la herramienta http://appserv.lsi.upc.es/wessqos/.
Se ha diseñado el escenario para poder probar las siguientes características del sistema
WeSSQoS:
• Gestión de los atributos de calidad. El cliente puede solicitar los atributos de
calidad que le interesen y éstos pueden o no estar definidos en la información de
los WS que se están seleccionando. El caso básico se da cuando el cliente
pregunta por un subconjunto de los atributos que tiene el repositorio. El sistema
también permite que el cliente pida atributos que no están definidos para los WS,
en cuyo caso los atributos se tratarán como no definidos en el algoritmo de
ordenación.
• Repositorios donde buscar la información de los WS. El sistema permite buscar en
uno o más repositorios. Cada repositorio puede ser dinámico o estático. Cuando
se están utilizando más de un repositorio se ha considerado:
- Los WS de cada repositorio pueden ser diferentes. En este caso se
calculará la unión de los servicios de todos los repositorios.
- En distintos repositorios puede haber información de los mismos WS pero
los atributos definidos en los diferentes repositorios pueden no ser los
mismos. En este caso el algoritmo de selección combinará los atributos
seleccionando los que necesite de cada repositorio.
- En distintos repositorios puede haber información de los mismos WS y de
los mismos atributos. En este caso, de los atributos que están en más de
un repositorio se selecciona la información del repositorio más prioritario.
En la Figura 20 se muestra la implementación de la arquitectura y los datos
necesarios para poder hacer todas las pruebas descritas anteriormente. Se dispone de los
dos tipos de QoSReporitoryProxy. Los dos Monitor utilizan Axis, mientras que el DataBank
Capítulo 4: WeSSQoS
65
(que contiene información sobre dos dominios de WS) utiliza Glassfish. Junto a los
QoSRepositoryProxy se han incluido los nombres de algunos de los WS de los que se
tiene información. Estos servicios se han seleccionado para que se vea de cuáles hay
información en más de un repositorio y de qué atributos tienen información.
En el caso del Databank, se tiene información de todos los atributos que
proporciona la herramienta menos el CurrentResponseTime (CRT) y el CurrentAvailability
(CA). Para los servicios de los Monitor se muestran los atributos de los que se tiene
información para cada servicio. A parte del CRT y el CA, también hay información en
algunos servicios del AverageResponseTime (ART).
Toda esta información sirve para saber cuál será la combinación de atributos que
se tendrá en cuenta según el orden en que se pongan los repositorios. Por ejemplo si el
orden es Monitor1, Monitor2 y DataBank1; para el servicio CalculosEstadist (que está en
los 3) los ART, CRT y CA se cogerán del Monitor1 y el resto del DataBank1. En cambio, si
el orden fuese Monitor2, Monitor1 y DataBank1, el CRT se cogería del Monitor2, el ART y
CA del Monitor1 y el resto del DataBank1.
Figura 20. Escenario para las pruebas de WeSSQoS
Capítulo 5: Casos de prueba y resultados
66
CAPÍTULO 5: CASOS DE PRUEBA Y RESULTADOS
En este capítulo se especifican casos de prueba en donde se observa la funcionalidad del
banco de pruebas de esta tesis, así como, al sistema WeSSQoS. Aclarando que el
sistema WeSSQoS es un framework que integra al banco de pruebas implementado en
esta tesis para apoyar la evaluación de modelos de calidad existentes. Las pruebas
realizadas fueron planteadas manejando múltiples atributos de calidad y manejando un
solo modelo de selección de servicios Web. Al término de la especificación de las pruebas
se describen los resultados obtenidos.
Capítulo 5: Casos de prueba y resultados
67
5.1 Casos de prueba Las pruebas 1 a 7 descritas a continuación se realizaron sobre el dominio estadístico
descriptivo y sobre el servidor de aplicaciones Apache Tomcat con Axis 2:
Prueba 1. Consiste en utilizar un repositorio, en este caso es el banco de pruebas
de esta tesis con 10 servicios y cada servicio con 8 parámetros de calidad. Entonces, las
entradas desde el sistema WeSSQoS en sus respectivas secciones son:
� Repositories: el usuario selecciona o introduce el dominio estadístico
descriptivo y la dirección del banco de pruebas especificado.
� StakeholderRequirements: el usuario selecciona o introduce 8 atributos de
calidad, en este caso todos serán iguales a los que se encuentran en cada
servicio Web del banco. A continuación se especifican las entradas de esta
sección:
Atributo Valor MaxMin Mandatario
AverageRecoveryTime 30 True True
MaximumExecutionTime 35 True True
AverageExecutionTime 31 True True
MaximumResponseTime 20 True True
AverageResponseTime 15 True True
FaultFactor 0.5 True True
ResultAccuracyFactor 0.6 True True
Cost 160 True True
Resultado esperado: de acuerdo a la especificación de la prueba no habrá
combinación de servicios entre repositorios, no habrá combinación de datos entre
repositorios y no habrá combinación de datos entre cliente y repositorio base. Por otro
lado, se espera que sean procesados los parámetros de calidad dados por el cliente
contra los parámetros de cada servicio en el banco de pruebas. Se muestran al cliente los
Capítulo 5: Casos de prueba y resultados
68
resultados priorizados por la distancia euclidiana de cada servicio Web del banco (de
menor a mayor distancia). Los resultados deben cumplir con la siguiente estructura:
nombre del servicio, URL del WSDL, EndPoint, descripción del servicio, distancia
euclidiana, contador mandatario (en éste caso todos los parámetros son de interés para el
cliente), parámetros de calidad con su respectivo mandatario (en éste caso al cliente le
interesan valores >= al valor solicitado).
Prueba 2. Consiste en utilizar un repositorio, en este caso es un monitor con 10
servicios y cada servicio con 7 parámetros de calidad. Entonces, las entradas desde el
sistema WeSSQoS en sus respectivas secciones son:
� Repositories: el usuario selecciona o introduce el dominio estadístico
descriptivo y la dirección del monitor especificado.
� StakeholderRequirements: el usuario selecciona o introduce 8 atributos de
calidad, en este caso 7 atributos se encuentran en el monitor y 1 no se
encuentra en el repositorio porque no fue monitorizado. A continuación se
especifican las entradas de esta sección:
Atributo Valor MaxMin Mandatario
AverageRecoveryTime 30 False True
MaximumExecutionTime 35 True True
AverageExecutionTime 31 False True
MaximumResponseTime 20 True True
AverageResponseTime 15 False True
FaultFactor 0.5 True True
ResultAccuracyFactor 0.6 False True
Cost 160 True True
Resultado esperado: de acuerdo a la especificación de la prueba no habrá
combinación de servicios entre repositorios; no habrá combinación de datos entre
repositorios; y sí habrá combinación de datos entre cliente y repositorio base, el costo se
Capítulo 5: Casos de prueba y resultados
69
agrega a cada servicio proveniente del monitor con valor igual a cero para su cálculo, pero
se muestra al cliente como no especificado. Por otro lado, se espera que sean
procesados los parámetros de calidad dados por el cliente contra los parámetros de cada
servicio monitorizado. Se muestran al cliente los resultados priorizados por la distancia
euclidiana de cada servicio Web monitorizado (de menor a mayor distancia). Los
resultados deben cumplir con la siguiente estructura: nombre del servicio, URL del WSDL,
EndPoint, descripción del servicio, distancia euclidiana, contador mandatario (en éste
caso todos los parámetros son de interés para el cliente), parámetros de calidad con su
respectivo mandatario (en éste caso al cliente le interesan valores >= y <= al valor
solicitado).
Prueba 3. Consiste en utilizar dos repositorios, en este caso es un monitor con 10
servicios y cada servicio con 7 parámetros de calidad; un banco de pruebas con 10
servicios y cada servicio con 8 parámetros de calidad. Entonces, las entradas desde el
sistema WeSSQoS en sus respectivas secciones son:
� Repositories: el usuario selecciona o introduce el dominio estadístico
descriptivo, la dirección del monitor y banco de pruebas especificado.
� StakeholderRequirements: el usuario selecciona o introduce 8 atributos de
calidad, en este caso 7 atributos se encuentran en el monitor y 1 no se
encuentra en el repositorio porque no fue monitorizado; en el banco se
encuentran los 8 atributos. A continuación se especifican las entradas de esta
sección:
Atributo Valor MaxMin Mandatario
AverageRecoveryTime 30 False True
MaximumExecutionTime 35 True False
AverageExecutionTime 31 False True
MaximumResponseTime 20 True False
AverageResponseTime 15 False True
FaultFactor 0.5 True False
Capítulo 5: Casos de prueba y resultados
70
ResultAccuracyFactor 0.6 False True
Cost 160 True False
Resultado esperado: de acuerdo a la especificación de la prueba no habrá
combinación de servicios entre repositorios porque los servicios que contienen son
iguales; sí habrá combinación de datos entre repositorios porque el costo se encuentra en
cada servicio del banco, puesto que no se encuentra en el repositorio base (monitor
priorizado) y son iguales los servicios entre repositorios el atributos es agregado a cada
servicio del monitor; y no habrá combinación de datos entre cliente y repositorio base. Por
otro lado, se espera que sean procesados los parámetros de calidad dados por el cliente
contra los parámetros de cada servicio monitorizado (repositorio base). Se muestran al
cliente los resultados priorizados por la distancia euclidiana de cada servicio Web
monitorizado (de menor a mayor distancia). Los resultados deben cumplir con la siguiente
estructura: nombre del servicio, URL del WSDL, EndPoint, descripción del servicio,
distancia euclidiana, contador mandatario (en éste caso algunos de los parámetros no son
de interés para el cliente), parámetros de calidad con su respectivo mandatario (en éste
caso al cliente le interesan valores >= y <= al valor solicitado).
Prueba 4. Consiste en utilizar dos repositorios, en este caso es un monitor con 8
servicios y cada servicio con 7 parámetros de calidad; un banco de pruebas con 10
servicios y cada servicio con 8 parámetros de calidad. Entonces, las entradas desde el
sistema WeSSQoS en sus respectivas secciones son:
� Repositories: el usuario selecciona o introduce el dominio estadístico
descriptivo, la dirección del monitor y banco de pruebas especificado.
� StakeholderRequirements: el usuario selecciona o introduce 8 atributos de
calidad, en este caso 7 atributos se encuentran en el monitor y 1 no se
encuentra en el repositorio porque no fue monitorizado; en el banco se
encuentran los 8 atributos. A continuación se especifican las entradas de esta
sección:
Capítulo 5: Casos de prueba y resultados
71
Atributo Valor MaxMin Mandatario
AverageRecoveryTime 30 False True
MaximumExecutionTime 35 True False
AverageExecutionTime 31 False True
MaximumResponseTime 20 True False
AverageResponseTime 15 False True
FaultFactor 0.5 True False
ResultAccuracyFactor 0.6 False True
Cost 160 True False
Resultado esperado: de acuerdo a la especificación de la prueba sí habrá
combinación de servicios entre repositorios porque el repositorio base en este caso el
monitor, no contiene algunos servicios que contiene el banco; sí habrá combinación de
datos entre repositorios porque el costo se encuentra en cada servicio del banco, puesto
que no se encuentra en el repositorio base (monitor priorizado) y son iguales los servicios
entre repositorios el atributos es agregado a cada servicio del monitor, excepto a los
servicios que ya lo contengan; y no habrá combinación de datos entre cliente y repositorio
base. Por otro lado, se espera que sean procesados los parámetros de calidad dados por
el cliente contra los parámetros de cada servicio monitorizado (repositorio base). Se
muestran al cliente los resultados priorizados por la distancia euclidiana de cada servicio
Web monitorizado (de menor a mayor distancia). Los resultados deben cumplir con la
siguiente estructura: nombre del servicio, URL del WSDL, EndPoint, descripción del
servicio, distancia euclidiana, contador mandatario (en éste caso algunos de los
parámetros no son de interés para el cliente), parámetros de calidad con su respectivo
mandatario (en éste caso al cliente le interesan valores >= y <= al valor solicitado).
Prueba 5. Consiste en utilizar dos repositorios, en este caso es un monitor con 8
servicios y cada servicio con 7 parámetros de calidad; un banco de pruebas con 10
servicios y cada servicio con 7 parámetros de calidad. Entonces, las entradas desde el
sistema WeSSQoS en sus respectivas secciones son:
Capítulo 5: Casos de prueba y resultados
72
� Repositories: el usuario selecciona o introduce el dominio estadístico
descriptivo, la dirección del monitor y banco de pruebas especificado.
� StakeholderRequirements: el usuario selecciona o introduce 8 atributos de
calidad, en este caso 7 atributos se encuentran en el monitor y 1 no se
encuentra en el repositorio porque no fue monitorizado; en el banco se
encuentran 7 atributos. A continuación se especifican las entradas de esta
sección:
Atributo Valor MaxMin Mandatario
AverageRecoveryTime 30 False True
MaximumExecutionTime 35 True False
AverageExecutionTime 31 False True
MaximumResponseTime 20 True False
AverageResponseTime 15 False True
FaultFactor 0.5 True False
ResultAccuracyFactor 0.6 False True
Cost 160 True False
Resultado esperado: de acuerdo a la especificación de la prueba sí habrá
combinación de servicios entre repositorios porque el repositorio base en este caso el
monitor, no contiene algunos servicios que contiene el banco; no habrá combinación de
datos entre repositorios porque el repositorio base contiene los mismos parámetros que el
banco; y sí habrá combinación de datos entre cliente y repositorio base porque el costo se
agrega a cada servicio proveniente del monitor con valor igual a cero para su cálculo, pero
se muestra al cliente como no especificado. Por otro lado, se espera que sean
procesados los parámetros de calidad dados por el cliente contra los parámetros de cada
servicio monitorizado (repositorio base). Se muestran al cliente los resultados priorizados
por la distancia euclidiana de cada servicio Web monitorizado (de menor a mayor
distancia). Los resultados deben cumplir con la siguiente estructura: nombre del servicio,
URL del WSDL, EndPoint, descripción del servicio, distancia euclidiana, contador
Capítulo 5: Casos de prueba y resultados
73
mandatario (en éste caso algunos de los parámetros no son de interés para el cliente),
parámetros de calidad con su respectivo mandatario (en éste caso al cliente le interesan
valores >= y <= al valor solicitado).
Prueba 6. Consiste en utilizar dos repositorios, en este caso es un monitor con 8
servicios y cada servicio con 6 parámetros de calidad; un banco de pruebas con 10
servicios y cada servicio con 8 parámetros de calidad. Entonces, las entradas desde el
sistema WeSSQoS en sus respectivas secciones son:
� Repositories: el usuario selecciona o introduce el dominio estadístico
descriptivo, la dirección del monitor y banco de pruebas especificado.
� StakeholderRequirements: el usuario selecciona o introduce 8 atributos de
calidad, en este caso 6 atributos se encuentran en el monitor y 2 no se
encuentra en el repositorio porque no fueron monitorizados; en el banco se
encuentran 8 atributos. A continuación se especifican las entradas de esta
sección:
Atributo Valor MaxMin Mandatario
AverageRecoveryTime 30 False True
MaximumExecutionTime 35 True False
AverageExecutionTime 31 False True
MaximumResponseTime 20 True False
AverageResponseTime 15 False True
FaultFactor 0.5 True False
ResultAccuracyFactor 0.6 False True
Cost 160 True False
Resultado esperado: de acuerdo a la especificación de la prueba sí habrá
combinación de servicios entre repositorios porque el repositorio base en este caso el
monitor, no contiene algunos servicios que contiene el banco; Sí habrá combinación de
Capítulo 5: Casos de prueba y resultados
74
datos entre repositorios porque el costo se encuentra en cada servicio del banco, puesto
que no se encuentra en el repositorio base (monitor priorizado) y son iguales los servicios
entre repositorios el atributo es agregado a cada servicio del monitor, excepto a los
servicios que lo contienen; y sí habrá combinación de datos entre cliente y repositorio
base porque el atributo FaulFactor no se encuentra en ningún servicio del repositorio
base. El atributo mencionado se agrega a los servicios del monitor con valor igual a cero
para su cálculo, pero se muestra al usuario como no especificado. Por otro lado, se
espera que sean procesados los parámetros de calidad dados por el cliente contra los
parámetros de cada servicio monitorizado (repositorio base). Se muestran al cliente los
resultados priorizados por la distancia euclidiana de cada servicio Web monitorizado (de
menor a mayor distancia). Los resultados deben cumplir con la siguiente estructura:
nombre del servicio, URL del WSDL, EndPoint, descripción del servicio, distancia
euclidiana, contador mandatario (en éste caso algunos de los parámetros no son de
interés para el cliente), parámetros de calidad con su respectivo mandatario (en éste caso
al cliente le interesan valores >= y <= al valor solicitado).
Prueba 7. Consiste en utilizar dos repositorios, en este caso es un monitor con 8
servicios y cada servicio con 6 parámetros de calidad; un banco de pruebas con 10
servicios y cada servicio con 8 parámetros de calidad. Entonces, las entradas desde el
sistema WeSSQoS en sus respectivas secciones son:
� Repositories: el usuario selecciona o introduce el dominio estadístico
descriptivo, la dirección del monitor y banco de pruebas especificado.
� StakeholderRequirements: el usuario selecciona o introduce 4 atributos de
calidad, en este caso 2 atributos se encuentran en el monitor y 2 no se
encuentran en el repositorio porque no fueron monitorizados; en el banco se
encuentran 2 atributos iguales a los que el usuario ingreso y 2 diferentes. A
continuación se especifican las entradas de esta sección:
Atributo Valor MaxMin Mandatario
AverageRecoveryTime 30 False True
AverageExecutionTime 31 False True
Capítulo 5: Casos de prueba y resultados
75
MaximumResponseTime 20 True False
ResultAccuracyFactor 0.6 False True
Resultado esperado: de acuerdo a la especificación de la prueba sí habrá
combinación de servicios entre repositorios porque el repositorio base en este caso el
monitor, no contiene algunos servicios que contiene el banco; Sí habrá combinación de
datos entre repositorios porque existen parámetros de calidad que se encuentran en cada
servicio del banco que no se encuentran en el repositorio base (monitor priorizado). Como
son iguales los servicios entre repositorios el parámetro es agregado a cada servicio del
monitor, excepto a los servicios que lo contienen; y sí habrá combinación de datos entre
cliente y repositorio base porque existen atributos que no se encuentran en ningún
servicio del repositorio base. Los atributos no encontrados se agregan a los servicios del
monitor con valor igual a cero para su cálculo, pero se muestran al usuario como no
especificados. Por otro lado, se espera que sean procesados los parámetros de calidad
dados por el cliente contra los parámetros de cada servicio monitorizado (repositorio
base). Se muestran al cliente los resultados priorizados por la distancia euclidiana de
cada servicio Web monitorizado (de menor a mayor distancia). Los resultados deben
cumplir con la siguiente estructura: nombre del servicio, URL del WSDL, EndPoint,
descripción del servicio, distancia euclidiana, contador mandatario (en éste caso algunos
de los parámetros no son de interés para el cliente).
Prueba 8. Esta prueba también se realiza sobre el dominio estadístico descriptivo e
incluye todas las especificaciones de las pruebas 1 a 7, por lo tanto, se espera obtener
los mismos resultados. La diferencia importante es que esta prueba se realiza sobre el
servidor de aplicaciones GlassfishV2. Con esto se tiene a los repositorios en un servidor
diferente de donde se encuentra el sistema de selección por QoS.
Prueba 9. Esta prueba se realiza sobre el dominio predicción climatológica e incluye
todas las especificaciones de las pruebas 1 a 7, por lo tanto, se espera obtener los
mismos resultados. La diferencia importante es que esta prueba se realiza sobre el
servidor de aplicaciones GlassfishV2 y Axis2. Con esto se tiene a los repositorios
(monitores y bancos) en servidores diferentes que el sistema de selección por QoS.
Capítulo 5: Casos de prueba y resultados
76
5.2 Resultados La Tabla 11 muestra los resultados obtenidos de los casos de pruebas propuestos en el
punto anterior.
Tabla 11. Tabla de resultados Prueba Dominio CSR CDR CDCR Servidor No
satisfactorio Satisfactorio
Prueba 1 Estadístico No No No Axis2 Si Prueba 2 Estadístico No No Si Axis2 Si Prueba 3 Estadístico No Si No Axis2 Si Prueba 4 Estadístico Si Si No Axis2 Si Prueba 5 Estadístico Si No Si Axis2 Si Prueba 6 Estadístico Si Si Si Axis2 Si Prueba 7 Estadístico Si Si Si Axis2 Si Prueba 8 Estadístico Pruebas 1 a 7 GlassfishV2 Si Prueba 9 Climatológico Pruebas 1 a 7 GlassfishV2 Si
Como se puede observar en la Tabla 11, todas las pruebas fueron satisfactorias. Con ello
se ha observado un correcto funcionamiento del banco de pruebas y del algoritmo de
selección. Las pruebas que se realizaron sobre un mismo servidor de aplicaciones
mostraron mayor velocidad de respuesta, en cambio las pruebas que en su especificación
utilizan diferente servidor de aplicaciones muestra menor velocidad de respuesta que
acceder a un mismo servidor, pero al obtener resultados se puede observar que el
sistema WeSSQoS y los repositorios son independientes de la plataforma.
Con las pruebas realizadas y los resultados obtenidos podemos decir que el banco
de pruebas está listo para ser utilizado por cualquier persona que desarrolle un algoritmo
de selección. Esto para que se realicen pruebas que aporten una evaluación de
resultados, arrojados por él o los algoritmos a probar. También se puede observar que se
ha puesto a disposición el sistema WeSSQoS que se puede utilizar para seleccionar
servicios Web por la calidad que los definen.
Capítulo 6: Conclusiones y trabajos futuros
77
CAPÍTULO 6: CONCLUSIONES Y TRABAJOS FUTUROS En el ámbito de la selección y composición de servicios Web, uno de los problemas más
relevantes es la selección por QoS. Actualmente existen muchas propuestas para
solucionar el problema utilizando QoS, sin embargo, se carece de los medios para
comprobar los resultados de esas propuestas. Atendiendo a esa problemática, la
aportación de esta tesis consiste en la generación de un banco de pruebas que contiene
servicios Web cuyas descripciones incluyen características de calidad también conocidas
como QoS. Otra de las aportaciones importantes es el desarrollo del sistema WeSSQoS
con el cual se obtuvieron beneficios tales como probar el banco de pruebas generado en
esta tesis junto con el algoritmo de selección de servicios Web que utiliza como función
objetivo la formula matemática distancia Euclidiana.
Debido a lo anterior, se concluye que el objetivo de esta tesis se cumplió gracias al
establecimiento de un conjunto de servicios Web que funcionan como banco de pruebas
para determinar si los modelos de selección de servicios que utilizan parámetros de
calidad también conocidos como QoS aportan resultados aceptables. Para poder lograr el
objetivo fue necesario seleccionar un conjunto de atributos de calidad que proporcionan
Capítulo 6: Conclusiones y trabajos futuros
78
información sobre los servicios Web para propósitos de apoyar el proceso de selección y
composición de los mismos.
Cabe resaltar que se superaron los alcances y se redujeron limitaciones de este
proyecto de tesis, ya que, se esperaba determinar entre 2 y 4 atributos de calidad y
finalmente se establecieron 8; se esperaba generar 80 servicios Web en el banco de
pruebas con un solo dominio, pero finalmente fueron 114 servicios repartidos en 2
dominios, 80 sobre el dominio de estadística descriptiva y 30 sobre predicción
climatológica. Las pruebas que se realizaron con el banco utilizaron sólo un modelo de
selección con lo cual se obtuvieron los resultados esperados. Al finalizar la
implementación del banco se pretendía que se compartiera sólo en la red local de
CENIDET, pero gracias al apoyo del grupo GESSI de la UPC el banco está disponible en
la Internet.
Acerca del sistema WeSSQoS se puede mencionar que cumple con algunas
características tales como:
• Propone una arquitectura orientada a servicios (SOA) totalmente abierta, en el que
los diferentes usuarios del sistema puedan eventualmente incorporar servicios
propios respetando el interfaz de los servicios utilizados.
• Es independiente de la ontología de atributos de calidad utilizada. La interfaz del
sistema permite seleccionar atributos de un conjunto predefinido o ingresar
atributos propios. Como la mayoría de sistemas, WeSSQoS trabaja tanto con
atributos estáticos como dinámicos.
• Permite leer los valores de los atributos de calidad de los WS tanto de las
descripciones de la definición del servicio como de sistemas de monitorización. El
uso de una clase Proxy compartida permite tratar ambos casos de forma uniforme
en el sistema e incluso pensar de añadir nuevas formas de obtención de valores.
• Permite trabajar con cualquier algoritmo de ordenación/selección de servicios que
respete la interfaz definida en la arquitectura. Eventualmente se podría pensar en
usar algoritmos arbitrariamente complejos, por ejemplo, integradores de resultados
mediante coreografía de otros WS que definieran algoritmos varios.
Capítulo 6: Conclusiones y trabajos futuros
79
• Permite utilizar un número arbitrario de repositorios de WS con independencia de
la tecnología utilizada, y además provee un mecanismo de combinación de
resultados cuando un mismo WS aparece en más de un repositorio. Actualmente,
el usuario es responsable de elegir repositorios “compatibles”, es decir, que
manejen dominios de software compatibles, que utilicen una ontología de calidad
similar, etc.
• Un primer prototipo de WeSSQoS está disponible en
http://appserv.lsi.upc.es/wessqos/ para su libre uso. La disponibilidad de tal
prototipo es consecuencia directa de haber diseñado el sistema mediante SOA
abierto. En su versión actual, el sistema ha sido probado sobre dos dominios de
software y 10 atributos tanto estáticos como dinámicos.
Las experiencias al desarrollar esta tesis son muy satisfactorias, ya que, se realizó
un trabajo que cubre expectativas importantes en el ámbito de selección y composición de
servicios Web. Todo el trabajo es una arquitectura orientada a servicios que proporciona
utilizar al banco de pruebas, al modelo de selección y a un integrador de los mismos,
como servicios Web. Finalmente, un hecho importante como resultado del trabajo
realizado es la publicación de un artículo internacional que tiene la siguiente referencia:
• Oscar Cabrera, Marc Oriol, Lidia López, Xavier Franch, Jordi Marco, Olivia
Fragoso, René Santaolaya. “WeSSQoS: Un Sistema SOA para la Selección de
Servicios Web según su Calidad”. V jornadas científico-técnicas en servicios Web
y SOA (JSWEB). 2009.
Como trabajo futuro, se identificaron diversas líneas:
• Efectuar pruebas a gran escala, con su correspondiente documentación.
• Ofrecer “de serie” un abanico de algoritmos de ordenación/selección.
• Completar las posibilidades de monitorización con capacidad de medición de más
atributos de calidad dinámicos.
• Pensar en mecanismos más sofisticados para combinar datos de los repositorios
(y unificar las diferentes estrategias resultantes bajo una misma interfaz,
definiéndolas como servicios reemplazables).
Anexo A: Análisis del modelo de selección basado en QoS
80
ANEXO A: ANÁLISIS DEL MODELO DE SELECCIÓN BASADO EN QoS
En este anexo se realiza el análisis de entrada y salida de datos del modelo de selección
de servicios Web por la calidad o QoS utilizado en esta tesis. Para realizar la
implementación del mismo se utilizaron las especificaciones del modelo en la referencia
del autor [Taher05] y además, se realizaron ejercicios de aplicación del algoritmo. El caso 1
que se describe a continuación establece un funcionamiento detallado del algoritmo, así
como la identificación de posibles casos alternos o de fracaso del mismo. El caso es el
siguiente:
Caso 1. Asumir QPc = [0.9, 20, 50, 0.9, 1, 200], qm = (WHM/NTM) y NR = {1, 0, 1,
1, 1, 0]. Las propiedades de QoS están en orden de escalabilidad, tiempo de respuesta,
rendimiento, disponibilidad, accesibilidad, costo. Basándose sobre las especificaciones
funcionales se asumen 4 servicios Web {WS1, WS2, WS3, WS4} que han sido retornados
por la UDDI. El algoritmo de búsqueda de QoS recupera las propiedades pertinentes a
QoS asociados con el modo qm de los 4 servicios web y se utilizan para construir la
matriz QoS, como se muestra a continuación:
Anexo A: Análisis del modelo de selección basado en QoS
81
Fase 1. Entrada de datos detallada en Figura 18
QoS=
QPc = [0.9, 20, 50, 0.9, 1, 200]
Fase 2: Normalizar la matriz QoS y QPc utilizando las formulas 2 y 3.
(2)
(3)
1.- Normalizar QPc.
QPc = [0.9, 20, 50, 0.9, 1, 200]
NR = [1, 0, 1, 1, 1, 0]
Norm (q ) = - = - = = 0.9 (aplicando formula 3)
Norm (q ) = - = - = = 0.0 (aplicando formula 2)
Norm (q ) = - = - = = 0.17 (aplicando formula 3)
Norm (q ) = - = – = = 0.75 (aplicando formula 3)
Norm (q ) = - = – = = 1 (aplicando formula 3)
Norm (q ) = - = - = = 0.75 (aplicando formula 2)
QPc Normalizada.
QPc = [0.9, 0.0, 0.17, 0.75, 1.0, 0.75]
2.- Normalizar la matriz QoS.
QoS =
Anexo A: Análisis del modelo de selección basado en QoS
82
Norm (q ) = - = - = = 0.9
Norm (q ) = - = - = = 0.67
Norm (q ) = - = - = = 0.44
Norm (q ) = - = – = = 1
Norm (q ) = - = – = = 0.75
Norm (q ) = - = - = = 0.00
Norm (q ) = - = - = = 0.00
Norm (q ) = - = - = = 0.33
Norm (q ) = - = - = = 0.06
Norm (q ) = - = – = = 0.50
Norm (q ) = - = – = = 0.00
Norm (q ) = - = - = = 1
Norm (q ) = - = - = = 0.30
Norm (q ) = - = - = = 1
Norm (q ) = - = - = = 0.06
Norm (q ) = - = – = = 0.00
Norm (q ) = - = – = = 0.75
Norm (q ) = - = - = = 0.75
WS1
WS2
WS3
Anexo A: Análisis del modelo de selección basado en QoS
83
Norm (q ) = - = - = = 1.00
Norm (q ) = - = - = = 0.00
Norm (q ) = - = - = = 1.00
Norm (q ) = - = – = = 0.75
Norm (q ) = - = – = = 1.00
Norm (q ) = - = - = = 0.50
Matriz QoS normalizada.
QoS =
Fase 3. Evaluar la distancia euclidiana entre la matriz de QoS y QPc normalizadas.
dis ( , = 2
Sw1.
(0.90 – 0.90)2 = 0.00
(0.67 – 0.00)2 = 0.4489
(0.44 – 0.17)2 = 0.0729
(1.00 – 0.75)2 = 0.0625
(0.75 – 1.00)2 = 0.0625
(0.00 – 0.75)2 = 0.5625
Sw1. = 1.2093
Sw1. = 1.0997
Sw2.
(0.00 – 0.90)2 = 0.81
(0.33 – 0.00)2 = 0.1089
(0.06 – 0.17)2 = 0.0121
(0.50 – 0.75)2 = 0.0625
(0.00 – 1.00)2 = 1.00
(1.00 – 0.75)2 = 0.0625
Sw2. = 2.056
Sw2. = 1.4339
WS4
Anexo A: Análisis del modelo de selección basado en QoS
84
Sw3.
(0.30 – 0.90)2 = 0.36
(1.00 – 0.00)2 = 1.00
(0.00 – 0.17)2 = 0.0289
(0.00 – 0.75)2 = 0.5625
(0.75 – 1.00)2 = 0.0625
(0.75 – 0.75)2 = 0.00
Sw3. = 2.0139
Sw3. = 1.4191
Sw4.
(1.00 – 0.90)2 = 0.01
(0.00 – 0.00)2 = 0.00
(1.00 – 0.17)2 = 0.6889
(0.75 – 0.75)2 = 0.00
(1.00 – 1.00)2 = 0.00
(0.50 – 0.75)2 = 0.0625
Sw4. = 0.7614
Sw4. = 0.8725
Fase 4. Encontrar la distancia Euclidiana mínima
Tabla 12. Prioridad de servicios caso 1 Servicio Distancia Euclidiana Prioridad
oListServicesDataForModel: list <ServiceDataForModel> oListStakeholderRequirementsForModel: list <StakeholderRequirementsForModel>
Respuesta:
oListServicesDataPriorityResultByModel: list <ServiceDataPriorityResultByModel>
Los atributos de los tipos ServiceDataForModel, MetricValueForModel, StakeholderRequirementsForModel, ServiceDataPriorityResultByModel, MetricValueByModel,… se pueden ver en el WSDL (apartado Other Types). <!-- REQUEST/RESPONSE TYPES -->
Referencias [Al-Masri07] E. Al-Masri, Q. Mahmoud. “QoS-based Discovery and Ranking of Web
Services”. Procs.16th Intl. Conference on Computer Communications and Networks (ICCCN 2007), 2007.
[Ameller08] D. Ameller, X. Franch. “Service Level Agreement Monitor
(SALMon)”. Procs. 7th IEEE Intl. Conference on Composition-Based Software Systems (ICCBSS), 2008.
[Bilin04] Bilin A. S., Singh M. P., “A DAML-Based Repository for QoS-Aware Semantic Web Service Selection”, Proceedings of the IEEE International Conference on Web Services (ICWS´04), IEEE Computer Society Press. (2004). pp 1-8.
[Carlos05] Carlos Lizárraga, ¿Qué es un Servicio Web? Departamento de Física, Universidad de Sonora [En línea]. Junio 2005 [Citado 2006- 06-08]. Disponible en Internet: http://www.fisica.uson.mx/carlos/WebServices/WSOverview.htm
[Carvallo06] J. P. Carvallo, X. Franch, C. Quer. “Managing Non-Technical Requirements in COTS Components Selection”. RE 2006.
[Chen05] Chen Zhou, Liang-Tien Chia and Bu-Sung Lee, “Semantics in Service Discovery and QoS Measurement”, Published by the IEEE Computer Society, April 2005.
[Gerardo04] Gerardo Canfora, Massimiliano Di Penta, Raffaele Esposito, Francesco Perfetto, and Maria Luisa Villani, “Service composition (re) binding driven by application-specific QoS”. RCOST – Research Centre on Software Technology University of Sannio, Italy.
[IEC697] IEC 60050-191, International Electrotechnical Vocabulary – Chapter 191: Dependability and quality of service.
[Isaac04] Isaac Moisés Vásquez Méndez: Generación de servicios web a partir de software legado. Centro Nacional de Investigación y Desarrollo Tecnológico. Cuernavaca Morelos, México. Tesis maestría. Diciembre 2007.
[Ismael06] Ismael Solís Moreno: Sistema de búsqueda y selección de servicios Web. Centro Nacional de Investigación y Desarrollo Tecnológico. Cuernavaca Morelos, México. Tesis maestría. Octubre 2006.
Referencias
95
[ISO001] International Organization for Standarization. ISO/IEC Standard 9126: SoftwareEngineering – Product Quality, part 1. 2001.
[ISOI97] ISO/IEC 2382-14:1997, Information technology – Vocabulary – Reliability, Maintainability and availability.
[ISO986] International Organization for Standarization. ISO Standard 8402: Quality management and quality assurance-Vocabulary, 1986.
[ISO994] ISO 9001:1994, Quality systems – Model for quality assurance in design, development, production, installation and servicing.
[J.Hu05] J. Hu, C. Guo, H. Wang, P. Zou. “Quality Driven Web Services
Selection”. Procs. IEEE International Conference on e-Business Engineering (ICEBE 2005), 2005.
[Jinghai04] Jinghai Rao, Peep Kungas, “Logic-based Web Services Composition: from Service Description to Process Model”, Department of Computer and Information Science, Norwegian University Science and Technology, N-7491, Trondheim, Norway.
[LiuY04] Liu Y., Ngu A.H.H. Zeng L., “QoS Computation and Policing in Dynamic Web Service Selection”, May17-22, 2004, New York, New York.
[Maria06] Maria Cecilia Bastarrica, “Atributos de Calidad y Arquitectura del Software”, departamento de ciencias de la computación, universidad de Chile.
[Marc08] Marc Oriol, Jordi Marco, Xavier Franch, David Ameller, “Monitoring Adaptable SOA-Systems using SALMon”, Universidad Politécnica de Cataluña, España.
[Maximilien05] E.M. Maximilien, M.P. Singh. “Multiagent System for Dynamic Web
Services Selection”. Procs. 1st Workshop on Service-Oriented Computing and Agent-Based Engineering (SOCABE), 2005.
[Menasce02] Menasce D., QoS Issues in Web Services, IEEE Internet Computing, Vol. 6, No. 6 November – December (2002). pp 72-75
[Murray06] Murray Woodside (Carleton University), Daniel A. Menascé (George Mason University). “Application – Level QoS”, Published by the IEEE Computer Society, May – June 2006.
[Papazoglou07] M.P. Papazoglou. Web Services: Principles and Technology. Pearson - Prentice Hall, 2007.
Referencias
96
[Papazoglou03] M.P. Papazoglou. “Service-Oriented Computing: Concepts, Characteristics and Directions”. In Proceedings of the Fourth International Conference on Web Information Systems Engineering, p.3, December 10-12, 2003.
[Patrik05] Patrik Berander, Lars-Ola, Damm, Jeanette Eriksson, Tony Gorschek. Software quality attributes and trade-offs. Blekinge Institute of Technology. Junio 2005.
[Praveen06] Praveen Sharma, Joseph Loyall, Richard E. Schantz, Jianming Ye, Prakash Manghwani, Matthew Gillen, “Managing End-to-End QoS in Distributed Embedded Applications”, Published by the IEEE Computer Society, May – June 2006.
[Ran03] Ran Shuping: A Model for Web Services Discovery With QoS, ACM SIGecom Exchanges, Vol. 4, Issue 1, March (2003). pp 1-10
[Robertson07] S. Robertson, J. Robertson. Mastering the Requirements Process (2nd Edition). Addison-Wesley, 2007.
[Samper05] Samper J.J, “Ontologías para servicios Web semánticos de información de tráfico: descripción y herramientas de explotación”, Departamento de Informática, Universidad de Valencia. [Citado 2007-05-14].
[Scotts06]
Scotts Valley, “Guia del desarrollador de servicios Web”, Borland JBuilder, Borland Software Corporation, 100 Enterprise Way, CA 95066-3249, Version 9.
[Silvana07] Silvana De Gyvés Avila: Composición de Servicios Web Utilizando Diagramas de Actividad. Centro Nacional de Investigación y Desarrollo Tecnológico. Cuernavaca Morelos, México. Tesis maestría. Diciembre 2007.
[Simona06] Simona Bernardi, José Merseguer, “QoS Assessment via Stochastic Analysis”, Published by the IEEE Computer Society, May – June 2006.
[Stencil02] The Stencil Group, Inc., “The Evolution of UDDI ”, the stencil group, 41 Freelon Street, San Francisco, California, Julio 2002.
[Taher05] L. Taher, H. El Khatib. “A Framework and QoS Matchmaking
Algorithm for Dynamic Web Services Selection”. Procs. 2nd International Conference on Innovations in Information Technology (IIT’05), 2005.
[Thomas04] Thomas Erl, “Service-Oriented Architectura, A Field Guide to Integrating XML and Web Services”, PRENTICE HALL/PTR, Upper Sanddle River, New Jersey 07458.
Referencias
97
[Tomc06] Tomcat Apache. The Apache Software Foundation [En línea]. Disponible en Internet: <http://tomcat.apache.org/>
[Valeria07] Valeria Cardellini, Emiliano Casalicchio, Vincenzo Grassi, Francesco Lo Presti. Scalable Service Selection for Web Service Composition Supporting Differentiated QoS Classes. Departamento de informática. Universidad de Roma. Technical Report RR-07.59. Italia. 2007.
[Vincenzo06] Vincenzo Grassi, Simone Patella, “Reliability Prediction for Service-Oriented Computing Environments”, Published by the IEEE Computer Society, May – June 2006.
[Wang06] X. Wang, T. Vitvar, M. Kerrigan, I. Toma. “A QoS-Aware Selection
Model for Semantic Web Services”. Procs. Int. Conf. on Service-Oriented Computing (ICSOC 2006), 2006
[W3C06]
W3C Oficina Española: Guía Breve de Tecnologías XML. [Citado 2007-05-14]. Disponible en línea: http://www.w3c.es/Divulgacion/Guiasbreves/TecnologiasXML
[Wiki09a] WikiPedia “La enciclopedia libre”. SOA [En línea]. Agosto 2009
[Citado 2009-08-11]. Disponible en Internet: <http://es.wikipedia.org/wiki/Arquitectura_orientada_a_servicios>.
[YuT05a] Yu T., Lin K. J, “Service Selection Algorithms for Composing Complex Services with Multiple QoS Constraints”, Proceedings of the 3rd International Conference on Service Oriented Computing ISOC 2005, Amsterdam The Netherlands December 12-15.
[YuT05b] Yu T., Lin K. J, “Service Selection Algorithms for Web Services with End-to-End QoS Constraint”, Journal of Information Systems and e-Business Management, Vol. 3, Num.2, July 2005, pp 1-19, 103-126.
[YuT05c] T. Yu, K. J. Lin. “A Broker-based Framework for QoS-aware Web
Service Composition”. Procs. IEEE Intl.’ Conference on E-Technology, e-Commerce and e-Service (EEE’05), 2005.