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
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.
AgradecimientosAgradecimientosAgradecimientosAgradecimientos
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
Language), XLink (XML Linking Language), XPointer (XML Pointer Language) y XQL
(XML Query Language)”.
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
factores de calidad.
Mantenimiento Flexibilidad
Pruebas Portabilidad Reusabilidad
Interoperabilidad Correcto Fiable Eficiente Integro Usable
Transiciones del producto
Operaciones del producto
Revisión de producto
Capítulo 3: Banco de pruebas
28
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
Correctitud * Fiabilidad * * Eficiencia * * Integridad * * Usabilidad * Mantenibilidad * * Facilidad de prueba * Flexibilidad * Portabilidad * * Reusabilidad * Interoperabilidad * Rastreabilidad * Consistencia * * Precisión * * Tolerancia a fallos * Operatividad * Simplicidad * Modularidad * Utilidad * Testabilidad * Entendibilidad * Modificabilidad * Accesibilidad * Ingeniería humana *
Capítulo 3: Banco de pruebas
31
3.1.3 Estándar ISO/IEC 9126
La evaluación de productos de software de éste estándar se enfoca en: características de
calidad y directrices para su uso como lo muestra la Figura 9.
Figura 9. ISO 9126, características de calidad y directrices para su uso
Este estándar se basa en el modelo de McCall y en el modelo de Boehm. Además
de ser estructurado básicamente de la misma forma que estos modelos como se observa
en la Figura 10. ISO 9126 incluye a la funcionalidad como un parámetro, así como
también identifica características de calidad internas y externas de productos de software.
El modelo de calidad ISO/IEC 9126 contiene 4 partes:
- Parte 1: modelo de calidad;
- Parte 2: métricas externas;
- Parte 3: métricas internas;
- Parte 4: calidad en uso de métricas.
Están los requerimientos funcionales disponibles en el software?
Que tan fácil es transferir el software a otro ambiente?
Que tan fácil es modificar el software?
Que tan eficiente es el software?
Es fácil de usar el software?
Que tan fiable es el software?
Fiabilidad
Eficiencia
Usabilidad
Portabilidad
Funcionalidad
Mantenibilidad
ISO/IEC 9126
Capítulo 3: Banco de pruebas
32
Tabla 4. Comparación entre los modelos de calidad McCall, Boehm e ISO 9126 Criterios/Metas McCall, 1977 Boehm, 1978 ISO 9126, 1993
Funcionalidad * Correctitud * Fiabilidad * * * Eficiencia * * * Integridad * * Usabilidad * * Mantenibilidad * * * Facilidad de prueba * Flexibilidad * Portabilidad * * * Reusabilidad * Interoperabilidad * * Rastreabilidad * Consistencia * * Precisión * * * Tolerancia a fallos * * Operatividad * * Simplicidad * Modularidad * Utilidad * Testabilidad * * Entendibilidad * Modificabilidad * Accesibilidad * Ingeniería humana * Conformidad * Seguridad * Tiempo de respuesta - - - Costo - - - Disponibilidad - - -
ISO 9126 propone un estándar que especifica 6 áreas de importancia, por ejemplo
factores de calidad para evaluación de software. La Tabla 4 muestra una comparativa por
factor calidad de los tres modelos según [Patrik05].
Capítulo 3: Banco de pruebas
33
Figura 10. Modelo de calidad ISO/IEC 9126
Cada factor de calidad y sus correspondientes sub-factores se definen de la siguiente
manera:
• Funcionalidad: un conjunto de atributos que se relacionan a la existencia de un
conjunto de funciones y propiedades especificas. Las funciones son aquellas que
satisfacen necesidades establecidas o que se dieron a entender.
� Conveniencia: atributo de software que se relaciona a la presencia y
conveniencia de un conjunto de funciones para tareas específicas.
� Precisión: atributos de software de acuerdo a los resultados o efectos.
Madurez
Tolerancia a fallas
Recuperabilidad
Conformidad
Analizable
Mutabilidad
Estabilidad
Testabilidad
Conformidad
Comprensibilidad
Capacidad de aprender
Atractivo
Operabilidad
Conformidad
Sub-Factores
Seguridad
Conformidad
Utilización de recursos
Co-existencia
Conformidad
Adaptabilidad
Precisión
Interoperabilidad
Comportamiento en el tiempo
Conformidad
Capacidad para instalar
Capacidad de ser reemplazado
Conveniencia
Factores
Fiabilidad I
S
O
/
I
E
C
9
1
2
6
Usabilidad
Eficiencia
Mantenibilidad
Portabilidad
Funcionalidad
Capítulo 3: Banco de pruebas
34
� Seguridad: atributos de software que se relacionan a la capacidad para
impedir el acceso no autorizado, ya sea accidental o deliberado, a los
programas y datos.
� Interoperabilidad: atributos de software que se relacionan a la capacidad
para interactuar con sistemas específicos.
• Fiabilidad: un conjunto de atributos que se relacionan a la capacidad del software
para mantener su nivel de desempeño bajo condiciones establecidas para un
periodo de tiempo establecido.
� Madurez: atributos de software que se relacionan a la frecuencia de falla
por defectos en el software.
� Tolerancia a fallas: atributos de software que se relacionan a la capacidad
para mantener un nivel especificado de desempeño en casos de defectos
de software.
� Recuperabilidad: atributos de software que se relacionan a la capacidad
para restablecer el nivel de desempeño y recuperar los datos directamente
afectados en caso de una falla y sobre el tiempo y esfuerzo necesario para
eso.
• Usabilidad: un conjunto de atributos que se relacionan al esfuerzo necesario para
su uso y sobre la evaluación individual de tal uso, por un conjunto de usuarios.
� Comprensibilidad: atributos de software que se relacionan al esfuerzo de
usuarios para reconocer el concepto lógico y su aplicabilidad.
� Capacidad de aprender: atributos de software que se relacionan al esfuerzo
de usuarios para el aprendizaje de la aplicación (por ejemplo: control de
operación).
� Operabilidad: atributos de software que se relacionan al esfuerzo de
usuarios para el funcionamiento y control de operación.
� Atractivo: La facilidad de uso es visible.
• Eficiencia: un conjunto de atributos que se refieren a la relación entre el nivel de
rendimiento del software y la cantidad de recursos utilizados, bajo condiciones
establecidas.
Capítulo 3: Banco de pruebas
35
� Comportamiento en el tiempo: atributos de software que se relacionan a la
respuesta y tiempo de procesamiento y sobre las tasas de rendimiento en
el desempeño de su función
� Utilización de recursos: atributos de software que se relacionan a la
cantidad de recursos utilizados y a la duración de dicha utilización en el
desempeño de su función.
• Mantenibilidad: un conjunto de atributos que se relacionan al esfuerzo necesario
para realizar las modificaciones especificadas.
� Analizable: atributos de software que se relacionan al esfuerzo necesario
para el diagnostico de deficiencias o causas de fracaso o para la
identificación de las partes a ser modificadas.
� Mutabilidad: atributos de software que se relacionan al esfuerzo necesario
para la modificación, eliminación de defectos o para el cambio de
ambiente.
� Estabilidad: atributos de software que se relacionan al riesgo de efectos
inesperados por modificaciones.
� Testabilidad: atributos de software que se relacionan con el esfuerzo
necesario para validar el software modificado.
• Portabilidad: un conjunto de atributos que se refieren a la capacidad del software
para ser transferido de un entorno a otro.
� Adaptabilidad: atributos de software que se refieren a la oportunidad para
su adaptación a diferentes ambientes especificados sin la aplicación de
otras acciones o medios que las previstas para este fin para el software
considerado.
� Capacidad para instalar: atributos de software que se relacionan al
esfuerzo necesario para instalar el software en un determinado ambiente.
� Co-existencia: atributos de software que hacen que el software se apegue a
estándares o a convenciones relacionadas a la portabilidad.
� Capacidad de ser reemplazado: atributos de software que se relacionan a
la oportunidad y esfuerzo de utilizarlo en el lugar especificado de otro
software en el ambiente de ese software.
Capítulo 3: Banco de pruebas
36
3.2 Aplicabilidad de los modelos de calidad
A través de la descripción de los modelos de calidad realizada en la sección
anterior se puede observar que los modelos de McCall y Boehm son muy similares ya que
manejan generalmente los mismos atributos y factores de calidad. El ISO/IEC 9126 parte
de los modelos McCall y Boehm pero se observa en su estructura jerárquica de atributos
que difiere de sus modelos base principalmente en dos atributos muy importantes en la
calidad de un servicio Web. Tales atributos son los de funcionalidad y seguridad.
Uno de los problemas que se puede observar en estos modelos es que no dan una
definición consensuada de las características o atributos de calidad que muestran en sus
modelos. Otro problema identificado es la falta de información de los atributos de calidad
para poder medirlos, añadido a todo esto, se puede encontrar una ausencia casi total de
métricas que permitan dar una estimación más objetiva de estos atributos. En
consecuencia, no existe un rango de valores explicito para los atributos de calidad que
ayude de cierta manera a la medición de los mismos.
Es importante mencionar que los modelos vistos proporcionan atributos de calidad
para temas muy generales respecto al desarrollo de software y su aplicación puede
centrarse en temas de un gran espectro. Por lo tanto, se observa la falta de modelos de
atributos de calidad que estén pensados para ofrecer soluciones a temas concretos, por
ejemplo, atributos específicos y de gran importancia para los servicios Web.
El modelo de calidad base para esta tesis es el estándar ISO 9126. Este modelo
es bastante completo, pero presenta dos problemas principales que limitan la selección de
atributos de calidad. El primero es la falta de precisión en la definición de los atributos,
mientras que el segundo se debe a que no todos esos atributos son aplicables a servicios
Web. Por lo tanto, se piensa que este estándar es idóneo como base de partida general,
pero es necesario refinarlo al caso particular de los servicios Web.
Considerando lo anterior, se realizó una preselección de atributos que se ocuparon
en el banco de pruebas de esta tesis, estos atributos fueron: funcionalidad, tiempo de
respuesta, costo, disponibilidad y fiabilidad. Aunque finalmente se encontraron trabajos
como el de [Ameller 08] que extienden la arquitectura del estándar ISO/IEC 9126 orientada
a servicios Web y considerando tal especificación se han sustituido los atributos
mencionados por los atributos de la Tabla 7.
Capítulo 3: Banco de pruebas
37
3.3 Atributos orientados a servicios Web En trabajos previos [Ameller08], se identifican los atributos de calidad de servicios
construyendo un modelo de calidad [ISO986]. El enfoque cumple con el estándar ISO/IEC
9126 [ISO001] y notablemente se han agregado algunas características relacionadas con
asuntos no técnicos siguiendo los consejos dados en [Carvallo06]. El modelo fue
desarrollado durante la participación en un proyecto Europeo ITEA, SODA (Servicios
Orientados a Dispositivos y Arquitecturas de entrega, www.soda-itea.org), en la cual se
tuvo la responsabilidad de identificar y clasificar las características necesarias para definir
la calidad de los servicios Web.
Figura 11: Características de calidad de los servicios Web
En el modelo de calidad propuesto en la Figura 11, se identificaron varias
características. Observe en la Figura 10 que, por ejemplo, una característica es eficiencia
y una de sus sub-características es el comportamiento en el tiempo. Pero el
comportamiento en el tiempo en si mismo no es sólo un concepto medible, por lo tanto se
necesitan definir atributos para descomponer esta sub-característica. Los atributos son
normalmente dependientes de que es lo que se quiere medir. En este caso, el enfoque es
sobre servicios Web. Tiempo de respuesta y tiempo de ejecución son buenos ejemplos de
atributos medibles para comportamiento en el tiempo.
El comportamiento en el tiempo es la capacidad del producto de software para
proporcionar tiempo de respuesta, tiempo de procesamiento y tasas de rendimiento
apropiadas en el desempeño de su función, bajo condiciones establecidas:
Servicios Web
Características técnicas (ISO/IEC 9126)
Características no técnicas (NT ISO/IEC 9126)
Figura 10
Acerca del servicio
- Continuidad - Atención al cliente - Capacidad de Prueba - Precio
Acerca del proveedor - Garantía de calidad - Identificación - Reputación - Escalabilidad - Sistema de seguridad
Capítulo 3: Banco de pruebas
38
• Tiempo de respuesta: mide el tiempo que toma un servicio Web para dar una
respuesta básica.
• Tiempo de ejecución: mide el tiempo que toma un servicio Web para ejecutar un
trabajo específico (un método, un proceso, etc.).
• La disponibilidad es el grado en que el sistema está operativo y en un estado
comprometido. El usuario podría querer asegurarse que un servicio está
disponible.
• La precisión es la capacidad del producto de software para proporcionar lo
correcto o resultados de acuerdo o efectos con el grado necesario de precisión. En
este caso, el usuario podría querer vigilar una funcionalidad concreta del servicio
Web, de esta manera, se puede hablar acerca de pruebas de funcionalidad.
Los atributos tiempo de respuesta y disponibilidad están relacionados. Si un
servicio Web no está disponible, ninguna de sus operaciones está disponible. Si el tiempo
de respuesta de un servicio Web se incrementa (ejemplo: por una demanda elevada del
servicio), el tiempo de ejecución de todas las operaciones del servicio Web se verán
afectadas en consecuencia. Por el contrario, tiempo de ejecución y precisión son atributos
que pertenecen a operaciones concretas del servicio Web.
Una vez que estos 4 atributos han sido identificados, el siguiente paso es
determinar las métricas concretas que serán objeto de medida. En la Tabla 5 se muestran
estas métricas.
Capítulo 3: Banco de pruebas
39
Tabla 5. Métricas estáticas y dinámicas Métrica Descripción
Disponibilidad actual Mide la disponibilidad actual de un servicio Web todo el tiempo o en fragmentos de
tiempo
Tiempo de disponibilidad
acumulado
Mide en porcentaje cuanto tiempo un servicio Web ha estado disponible desde que ha
sido monitorizado por primera vez
Tiempo de no
disponibilidad acumulado
Mide en porcentaje cuanto tiempo un servicio Web no ha estado disponible desde que ha
sido monitorizado por primera vez
Tiempo de recuperación
promedio
Mide en segundos el tiempo promedio que un servicio Web necesita para estar
disponible otra vez (se considera no disponible)
Tiempo de respuesta
actual
Mide el tiempo de respuesta actual en milisegundos para acceder a un servicio Web
Tiempo de respuesta
mínimo
Mide cual es el tiempo de respuesta más bajo en milisegundos para acceder a un servicio
Web
Tiempo de respuesta
máximo
Mide cual es el tiempo de respuesta máximo en milisegundos para acceder a un servicio
Web
Tiempo de respuesta
promedio
Mide cual es el tiempo de respuesta promedio en milisegundos para acceder a un
servicio Web
Tiempo de ejecución
actual
Mide el tiempo de ejecución actual en milisegundos que un servicio Web toma para
ejecutar un trabajo. (respuesta + ejecución)
Tiempo de ejecución
mínima
Mide cual es el tiempo de ejecución mínimo en milisegundos que un servicio Web toma
para ejecutar un trabajo
Tiempo de ejecución
máxima
Mide cual es el tiempo de ejecución máximo en milisegundos que un servicio Web toma
para ejecutar un trabajo
Tiempo de ejecución
promedio
Mide cual es el tiempo de ejecución promedio en milisegundos que un servicio Web
toma para ejecutar un trabajo
Cumplimiento de
funcionalidad actual
Mide el cumplimiento de funcionalidad actual de un servicio Web
Factor de precisión de
los parámetros
Divide el número de parámetros aceptados pasados a un método de un servicio Web por
el número de parámetros esperados por este método (1 es mejor)
Factor de precisión del
resultado
Divide el número de resultados de tipo correcto retornados por un método del servicio
Web por el número de resultados esperados de este método (1 es mejor)
Factor de error Divide el número de fallas que un método del servicio Web ha generado por el tiempo
total que este método a sido ejecutado (1 es peor)
Dis
po
nib
ilid
ad
Tie
mp
o d
e r
esp
ue
sta
Tie
mp
o d
e e
jecu
ció
nP
rue
ba
s d
e f
un
cio
na
lid
ad
Atr
ibu
tos
de
lo
s se
rvic
ios
We
bA
trib
uto
s d
e l
as
op
era
cio
ne
s
Existe una distinción importante entre métricas básicas y métricas derivadas. Las
métricas básicas son aquellas que deben ser monitorizadas para obtener sus valores.
Algunos ejemplos de métricas básicas son: tiempo de respuesta actual y disponibilidad
actual. Las métricas derivadas son aquellas que pueden ser obtenidas de un conjunto de
métricas básicas o a través de un conjunto de valores de una sola métrica básica. Por
ejemplo, tiempo de respuesta promedio es una métrica derivada que se puede obtener a
través de un conjunto de tiempos de respuesta actuales en un intervalo de tiempo.
Otro ejemplo es tiempo de recuperación en caso de fallo la cual también es una
métrica derivada de la métrica básica disponibilidad actual. Esta distinción es importante
ya que dado los valores de una métrica básica, no hay interacción con el seguimiento del
servicio para obtener los valores de las correspondientes métricas derivadas.
Capítulo 3: Banco de pruebas
40
3.3.1 Atributos de calidad monitorizables
Para propósitos de esta tesis se ha optado por utilizar el estándar ISO/IEC 9126 debido a:
1) es de naturaleza genérica: el estándar fija algunos conceptos de calidad de alto nivel y
por lo tanto modelos de calidad pueden ser adaptados para dominios específicos; 2)
permite crear jerarquías de características de calidad, lo cual es esencial para construir
modelos de calidad estructurados; 3) el estándar es generalizado.
ISO/IEC 9126-1 específicamente se refiere a la definición de modelos de calidad y
se utiliza como un framework para evaluación de Software.
Mantenibilidad, portabilidad y usabilidad son grupos de características que no
pueden ser monitorizadas, básicamente porque son características de diseño de Software
y no son pretendidos para cambiar en tiempo de ejecución. Por lo tanto, se concluye que
atributos que se pueden medir por técnicas de monitoreo sólo es un pequeño conjunto, es
decir, aquellos relacionados a las sub-características de disponibilidad, comportamiento
en el tiempo y precisión. Remarcando que precisión puede ser difícil de medir por la
necesidad de obtener información del servicio Web en concreto; para monitorizar la
precisión se necesita conocer la funcionalidad concreta del servicio y tener disponibilidad
concreta predefinida por pruebas de ejecución. La Tabla 6 es un ejemplo de métricas que
pueden ser usadas por el atributo tiempo de respuesta perteneciente a la característica
comportamiento en el tiempo.
Tabla 6. Métricas de tiempo de respuesta Métrica Descripción
Tiempo de respuesta
actual
Mide el tiempo de respuesta actual en milisegundos para acceder a un servicio Web
Tiempo de respuesta
mínimo
Mide cual es el menor tiempo de respuesta en milisegundos para acceder a un servicio
Web
Tiempo de respuesta
máximo
Mide cual es el tiempo de respuesta máximo en milisegundos para acceder a un servicio
Web
Tiempo de respuesta
promedio
Mide cual es el tiempo de respuesta promedio en milisegundos para acceder a un
servicio Web
Tie
mp
o d
e r
esp
ue
sta
Capítulo 3: Banco de pruebas
41
3.4 Selección de atributos de calidad La lista de atributos de calidad estáticos que se han seleccionado para conformar la
información de calidad de cada servicio Web en el banco de pruebas se muestra en la
Tabla 7. Estos atributos son los que se han identificado como derivados o estáticos, la
evaluación de éstos no es en tiempo de ejecución y en el contexto de esta tesis un banco
de pruebas no está pensado para actualizar su información de calidad.
Tabla 7. Atributos de calidad estáticos para servicios Web y rangos Atributo Rango de valores
Tiempo de recuperación promedio (AverageRecoveryTime) [Integer]
Tiempo de ejecución promedio (AverageExecutionTime) [Integer]
Tiempo de ejecución máximo (MaximumExecutionTime) [Integer]
Tiempo de respuesta promedio (AverageResponseTime) [Integer]
Tiempo de respuesta máximo (MaximumResponseTime) [Integer]
Factor de error (FaultFactor) [Real[0..1]]
Factor de precisión del resultado (ResultAccuracyFactor) [Real[0..1]]
Costo (Cost) [Real]
3.5 Dominios del banco de pruebas Esta tesis se enfoca en la construcción de un banco de pruebas el cual debe contener
servicios dummy. Este banco es conformado por dos dominios de aplicación dentro de los
cuales se organizan los servicios Web. Tales dominios son: el dominio de estadística
descriptiva y el dominio de predicción climatológica.
Por el lado del dominio de estadística descriptiva se lograron desarrollar 84
servicios Web y en el caso del dominio de predicción climatológica se desarrollaron 30
servicios Web. Cada WSDL de los servicios Web han sido extendidos con información de
calidad que los definen. En la Tabla 8 se muestran los nombres asignados a los servicios
del dominio estadístico descriptivo y en la Tabla 9 se muestran los nombres asignados a
los servicios de predicción climatológica.
Capítulo 3: Banco de pruebas
42
Tabla 8: Servicios del dominio estadístico descriptivo 1.- Servicio Estadistico 43.- EstadisticosGenerales 2.- Estadistica 44.- Promedios 3.- Calculos estadística 45.- ServTC 4.- ServDesvmedia 46.- EstadisticosCalculos 5.- ServVarianza_Mod 47.- Estadisticos_Calculos 6.- ServMediaAritmetica 48.- CalculosPromedios 7.- CalculosTendenciaCentral 49.- MedidasEstadisticas 8.- Servicio Web Estadistico 50.- Medianas y Modas 9.- Calculos 51.- DefMedia 10.- ServEstadistico 52.- DefModa 11.- Servicio_Medias_Estadisticas 53.- DefEstadisticos 12.- ServicioMediana 54.- DefMediana 13.- CalculosLocalizacion 55.- DefPromedios 14.- DispersionEstadistica 56.- S_Cal_Media 15.- CalculosPromedios 57.- S_Cal_Moda 16.- Servicio Localizacion 58.- S_Cal_Estadistica 17.- MedidasDispersion 59.- S_Cal_Mediana 18.- CalculoModa 60.- S_Cal_Promedios 19.- CalculoMediana 61.- S_Cal_EstadistDescriptiva 20.- CalculoDispersion 62.- DesviacionEstandar 21.- ServicioModa 63.- MediayDesviacionEstandar 22.- CLocalizacion 64.- DistribucionesEstadisticas 23.- ServicioTCentral 65.- ServDistribucionesEst 24.- CalculosEstadisticos 66.- ServDistEst 25.- Servicio_Moda1_Mediana 67.- Serv_Med_Estadist 26.- ServicioModa2_Mediana 68.- EstadisticoServicio 27.- ServicioMedia 69.- CalculosEstadist 28.- CalculoTCentral 70.- ServCalLocalizacion 29.- ServicioEstadistica 71.- ModaServCalculo 30.- ServCalculosEd 72.- MedianaServCalculo 31.- CalculosMediana 73.- DispersionServCalculo 32.- MediaAritmetica 74.- CalDesvEstadistica 33.- DesviacionEstadistica 75.- ServWebEstadisticos 34.- ServicioTendenciaCentral 76.- ServWebLocalizacion 35.- ServMedArmonica 77.- ServWebModa 36.- Estadistica Descriptiva 78.- ServWebMediana 37.- EstadisticaDescrip 79.- ServWebDesvEstand 38.- CalcDesvEstadistica 80.- ServWebCalEstadisticos 39.- SModa 81.- ServWebMedia 40.- SMedia 82.- ServWebPromedios 41.- SArmonica 83.- ServWebDispersion 42.- SDesvEstand 84.- ServWebEstDescriptiva
Capítulo 3: Banco de pruebas
43
Tabla 9. Servicios del dominio predicción climatológica 1.- AirportWeatherCheck 16.- TemperatureService 2.- AmolWeatherService 17.- USAWeatherForecast 3.- AustraliaandNewZealandWeatherService 18.- USWeather 4.- BerreWeather 19.- WeatherClimatologic 5.- DOTSFastWeather 20.- WeatherConditions 6.- fastweather2 21.- WeatherFetcherService 7.- GetDayForecastInfo 22.- WeatherForecastforSpain 8.- GetExtendedWeatherInfo 23.- weatherforecast 9.- GetNineDayForecastInfo 24.- WeatherII 10.- GetWeatherForecast 25.- WeatherMaker 11.- GetWeatherInfo 26.- Weather 12.- GlobalWeather 27.- WeatherServiceforWaterloo 13.- HurricaneServiceService 28.- WeatherService 14.- JuiceTemperatureService 29.- Weather_WS 15.- ndfdXML 30.- WeatherForecast2
3.6 Extensibilidad del WSDL El WSDL y otras especificaciones de servicios web soportan la extensibilidad. Es decir,
alguien que quiere indicar el precio por usar el servicio puede hacerlo con el WSDL, se
debe inventar la sintaxis en el lenguaje apropiado e insertarlo en el lugar correcto del
WSDL. El principio de extensibilidad del WSDL es de lo más estricto posible.
La capacidad de descripción de un WSDL está limitada a la herramienta que lo
genera, el esquema que lo define y le da estructura y si es hecho manualmente se limita
al proveedor que lo genera. En sí, la estructura y elementos que conforman a un WSDL
son muy estrictos y es por ello que si se desean extender este tipo de documentos debe
hacerse mediante definiciones y reglas de documentos XML. Un WSDL por default sigue
el sistema de datos definido en la especificación del esquema XML por la W3C.
El WSDL de un servicio web está definido por un esquema XML y cualquier
cambio o extensión al agregar un elemento al WSDL debe reflejarse en el esquema XML
(XSD). Estos documentos están escritos en XML así que debe de seguirse la filosofía del
mismo para hacer modificaciones y extensiones.
Las organizaciones como OASIS y W3C son encargadas de la arquitectura y
reglamentación de los servicios Web. La mayoría de IDEs (Netbeans, Eclipse, Visual
Studio,…) están reglamentados por las organizaciones previamente mencionadas y los
documentos XML definidos para cada servicio generado son bien estructurados. Aunque
Capítulo 3: Banco de pruebas
44
existe un problema de interoperabilidad entre WSDLs generados entre distintos IDEs ya
que no utilizan una misma sintaxis entre uno y otro.
Por lo anterior, si se requiere implementar un servicio Web de forma top down, es
decir, a partir de la definición del servicio (WSDL) es necesario apegarse a los
lineamientos de W3C, OASIS e IDE a utilizar. De otra manera, si se requiere implementar
de forma bottom up, es decir, desde un código existente éste debe apegarse a la forma de
codificar servicios Web del IDE utilizado.
3.6.1 Estructura y características del WSDL
Un documento WSDL típicamente contiene 2 grupos de definiciones: una abstracta y una
concreta, la parte abstracta describe como el servicio web hace en términos de los
mensajes su consumo y producción sin considerar “cómo” y “dónde” es ofrecido este
servicio. El “qué” parte de la descripción que está cubierta por el <types>, <message> y
<portType>. El “cómo” y “dónde” están cubiertas por el <binding> y <service>. A
continuación se describen las características de los 6 elementos de un WSDL.
• Definitions:
– Es la raíz del elemento WSDL;
– Define el nombre del servicio.
• Types:
– ¿Que tipos de datos serán transmitidos?;
– Describe todos los datos usados por el cliente y servidor;
– Pueden ser omitidos si solo se utiliza tipos de datos simples.
• Message:
– ¿Qué mensajes serán transmitidos?;
– Define el nombre del mensaje solicitud/respuesta;
– Define también al mensaje como parte de elementos.
• PortType:
– ¿Que operaciones serán soportadas?;
– Define la combinación de elementos del mensaje para formar una ruta
completa o una operación round-trip.
Capítulo 3: Banco de pruebas
45
• Binding:
– Como serán transmitidos los mensajes sobre el medio (Red, Cable, Medio
de transporte);
– Provee detalle específicos sobre como una operación portType realmente
será transmitida bajo el medio;
– Información específica de SOAP puede ser definida aquí.
• Service:
– ¿Dónde está el servicio localizado?;
– Define la dirección para invocar al servicio especificado.
• Documentation (menos usado comúnmente):
– Proporciona documentación que se pueda leer por el humano;
– Similar a hacer comentarios en un programa.
Una característica más que es necesario manejar al momento de extender un
WSDL es el espacio de nombres XML, el cual es una recomendación W3C para
proporcionar elementos y atributos con nombres únicos en una instancia XML. Por otro
lado, para generar esquemas XML correctos se debe considerar que un esquema es:
• Al igual que los DTDs, describen el contenido y la estructura, pero de una forma
más precisa.
• Indican tipos de datos, número mínimo y máximo de ocurrencias y otras
características más específicas.
• Los DTD no pueden ser representados vía DOM.
• Permite definir estructuras mas complejas que en los DTDs.
• Los elementos se pueden definir con tipos de datos específicos.
3.7 Creación del banco de pruebas En esta sección se muestra el proceso de creación del banco de pruebas utilizado en este
trabajo de tesis. Los pasos y especificaciones son las siguientes:
1. En este proyecto de tesis se utiliza NetBeans IDE 6.5 para crear los bancos de pruebas
correspondientes a los dominios estadístico descriptivo y predicción climatológica.
Capítulo 3: Banco de pruebas
46
2. Para crear un banco es necesario crear un proyecto Web en NetBeans de la siguiente
forma:
• File -> New Project -> Categories -> Java Web -> Projects -> Web Application ->
Next -> Name and Location -> Project Name: nombre del proyecto deseado ->
Project Location: dirección donde se desea guardar el proyecto -> Project Folder:
folder donde se guardan los archivos del proyecto -> Next -> Server and Settings -
> Server: seleccionar o agregar el servidor de aplicaciones deseado -> Java EE
Version: Seleccionar la versión de java que se desea manejar -> Finish.
3. Un servicio Web como parte de un banco de pruebas es aquel que en su WSDL
contiene la descripción de calidad que lo define, es decir, cada servicio en el banco debe
tener su WSDL extendido con parámetros (atributo-valor) de calidad que lo definen.
4. A partir del punto 3 se derivan 2 formas de generación de servicios con WSDL
extendido. Una forma es crear un servicio a partir de un WSDL, donde se debe crear la
estructura de un WSDL con los estándares definidos por OASIS y W3C. La forma descrita
implica generar un DTD o esquema que defina a cada servicio y finalmente siguiendo las
reglas de generación de documentos XML se realiza la extensión de cada WSDL con los
parámetros necesarios. Cuando se ha creado el WSDL extendido y validado sin errores,
crear el servicio Web de la siguiente manera:
• Clic derecho en el proyecto Web generado en el punto 2 -> New -> Web Service
from WSDL… -> Web Service Name: nombre deseado para el servicio Web ->
Package: paquete destino del código fuente -> Select Local WSDL File or Enter
WSDL URL: anotar directamente la dirección donde se encuentra el WSDL
extendido o con el botón Browse… buscar la ubicación del mismo -> Web Service
Port: si la dirección dada y validación del WSDL es correcta entonces el campo se
complementa automáticamente -> Finish.
5. Otra forma de crear un servicio Web con WSDL extendido es creando dos proyectos
Web, uno para que actúe como proyecto auxiliar, es decir, en ese proyecto se deben
crear todos los servicios Web de forma normal como los genera NetBeans y otro para
generar los servicios con WSDL extendido. El proceso se resume a continuación:
Capítulo 3: Banco de pruebas
47
• Crear dos proyectos Web como lo especifica el paso 2 -> especificar los nombres
de los proyectos (el nombre dado para el proyecto auxiliar en ésta tesis es
“BancoPruebas” y para el proyecto que realmente actúa como banco es
“BancoPredicciónClimatológica” en el caso de los servicios que pertenecen al
dominio predicción climatológica) -> Clic derecho sobre el proyecto auxiliar -> New
-> Java Package… -> Name and Location -> Package Name: nombre del paquete
(se almacenan los .java de cada servicio generado) -> Finish -> Clic derecho sobre
el proyecto auxiliar -> New -> Web Service… -> Name and Location -> Web
Service Name: nombre dado para el servicio Web -> Package: seleccionar el
paquete creado -> todos los demás campos dejarlos como están y clic en el botón
Finish.
6. Crear todos los servicios Web requeridos en el proyecto auxiliar como se realiza en el
punto anterior y generar al menos una operación por cada servicio creado (la operación
puede ser vacía). Una vez que se tengan todos los servicios creados en el proyecto Web
Auxiliar es momento de generar sus WSDLs como los genera NetBeans. El proceso es el
siguiente:
• Crear una carpeta en cualquier dirección deseada (lo mejor es crearla dentro del
proyecto Web raíz) -> ir al proyecto auxiliar generado -> Web Services y expandir
(aquí se encuentran todos los servicios generados) -> por cada servicio generar su
WSDL -> Clic derecho sobre el nombre del servicio -> Clic en Generate and Copy
WSDL… (si no apareciera la opción o no se genera el WSDL entonces antes se
debe desplegar el proyecto de la siguiente forma: clic derecho sobre el proyecto
Web -> Clic en Deploy) -> Select location in Project where WSDL will be copied:
seleccionar la carpeta creada anteriormente donde se desea copiar los WSDLs de
cada servicio Web -> Clic en el botón OK (si aparece una pregunta donde se dice
que el archivo existe seleccionar sobrescribir) -> ir a la carpeta que se ha
seleccionado como destino de los WSDLs generados y si todo es correcto por
cada servicio Web debe existir su WSDL y esquema que lo define.
7. Ahora se extenderán los WSDLs generados en el paso anterior, para extenderlos
primero se debe modificar su esquema correspondiente. El proceso de extensión para
cada esquema es el siguiente:
Capítulo 3: Banco de pruebas
48
• Agregar al esquema la siguiente línea: <xs:element name="QoSAttributes"
type="tns:QoSAttributes"/>, tal instrucción sirve para declarar un nuevo elemento
que debe aceptar el WSDL que define. En consecuencia de la línea anterior se
debe agregar al esquema el tipo complejo de la misma como sigue:
<xs:complexType name="QoSAttributes"></xs:complexType>. Tomando en cuenta
lo descrito cada esquema debe ser como el siguiente ejemplo:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<xs:schema version="1.0"
targetNamespace="http://pkgEstadisticoDescriptivo/"
xmlns:tns="http://pkgEstadisticoDescriptivo/"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="Calcular" type="tns:Calcular"/>
<xs:element name="CalcularResponse" type="tns:CalcularResponse"/>
<xs:element name="QoSAttributes" type="tns:QoSAttributes"/>
<xs:complexType name="Calcular">
<xs:sequence>
<xs:element name="dX1" type="xs:double"/>
<xs:element name="dX2" type="xs:double"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="CalcularResponse">
<xs:sequence>
<xs:element name="return" type="xs:double" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="QoSAttributes">
</xs:complexType>
</xs:schema>
8. Con las modificaciones de cada esquema como se describe anteriormente cada WSDL
está listo para extenderse con información de calidad que define a cada servicio Web.
Para agregar los parámetros de calidad a cada WSDL se realiza lo siguiente:
• A cada WSDL en la sección de message agregar las siguientes líneas XML:
<message name="QoSAttributes">
<part name="AverageRecoveryTime" element="tns:QoSAtributos">
<documentation>20</documentation>
</part>
<part name="MaximumExecutionTime" element="tns:QoSAtributos">
<documentation>30</documentation>
</part>
<part name="AverageExecutionTime" element="tns:QoSAtributos">
Capítulo 3: Banco de pruebas
49
<documentation>25</documentation>
</part>
<part name="MaximumResponseTime" element="tns:QoSAtributos">
<documentation>15</documentation>
</part>
<part name="AverageResponseTime" element="tns:QoSAtributos">
<documentation>10</documentation>
</part>
<part name="FaultFactor" element="tns:QoSAtributos">
<documentation>0.4</documentation>
</part>
<part name="ResultAccuracyFactor" element="tns:QoSAtributos">
<documentation>0.3</documentation>
</part>
<part name="Cost" element="tns:QoSAtributos">
<documentation>50</documentation>
</part>
</message>
• Con el fragmento anterior se observa que se especifican atributos de calidad así
como su respectivo valor (Los valores utilizados para cada banco de pruebas son
aleatorios). Se pueden agregar tantos atributos que se requieran siguiendo el
formato anterior (los atributos utilizados en ésta tesis son aquellos que tienen
sentido evaluarse estáticamente). Un WSDL extendido tendrá la forma siguiente:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<!-- Generated by JAX-WS RI at http://jax-ws.dev.java.net. RI's
version is JAX-WS RI 2.1.3.1-hudson-417-SNAPSHOT. -->
<definitions targetNamespace="http://pkgPrediccionClimatologica/"
name="AirportWeatherCheckService"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:tns="http://pkgPrediccionClimatologica/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
wssecurity-utility-1.0.xsd">
<types>
<xsd:schema>
<xsd:import namespace="http://pkgPrediccionClimatologica/"
schemaLocation="AirportWeatherCheckService_schema1.xsd"/>
</xsd:schema>
</types>
<message name="GetWeather">
<part name="parameters" element="tns:GetWeather"/>
</message>
<message name="GetWeatherResponse">
<part name="parameters" element="tns:GetWeatherResponse"/>
</message>
<message name="QoSAttributes">
<part name="AverageRecoveryTime" element="tns:QoSAtributos">
<documentation>20</documentation>
</part>
<part name="MaximumExecutionTime" element="tns:QoSAtributos">
Capítulo 3: Banco de pruebas
50
<documentation>30</documentation>
</part>
<part name="AverageExecutionTime" element="tns:QoSAtributos">
<documentation>25</documentation>
</part>
<part name="MaximumResponseTime" element="tns:QoSAtributos">
<documentation>15</documentation>
</part>
<part name="AverageResponseTime" element="tns:QoSAtributos">
<documentation>10</documentation>
</part>
<part name="FaultFactor" element="tns:QoSAtributos">
<documentation>0.4</documentation>
</part>
<part name="ResultAccuracyFactor" element="tns:QoSAtributos">
<documentation>0.3</documentation>
</part>
<part name="Cost" element="tns:QoSAtributos">
<documentation>50</documentation>
</part>
</message>
<portType name="AirportWeatherCheck">
<operation name="GetWeather">
<input message="tns:GetWeather"/>
<output message="tns:GetWeatherResponse"/>
</operation>
</portType>
<binding name="AirportWeatherCheckPortBinding"
type="tns:AirportWeatherCheck">
<soap:binding transport="http://schemas.xmlsoap.org/soap/http"
style="document"/>
<operation name="GetWeather">
<soap:operation soapAction=""/>
<input>
<soap:body use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
</binding>
<service name="AirportWeatherCheckService">
<port name="AirportWeatherCheckPort"
binding="tns:AirportWeatherCheckPortBinding">
<soap:address location="REPLACE_WITH_ACTUAL_URL"/>
</port>
</service>
</definitions>
Capítulo 3: Banco de pruebas
51
9. Con el segundo proyecto Web creado es momento de generar los servicios Web con
WSDL extendido. El proceso de generación es el siguiente:
• En NetBeans ubicarse en la raíz del proyecto Web -> Clic derecho -> New -> Web
Service from WSDL… -> Name and Location -> Web Service Name: nombre del
servicio Web el cual debe ser diferente al nombre del servicio que corresponde al
WSDL extendido que se ha de utilizar para crear este nuevo servicio -> Package:
se puede crear antes un paquete destino de los .java de cada servicio o utilizar el
paquete por default (el nombre del paquete debe ser diferente al nombre del
paquete origen del WSDL extendido a utilizar) -> Select Local WSDL File or Enter
WSDL URL: dirección del WSDL extendido, tal dirección buscarla con el botón
Browse… o anotarla directamente -> Web Service Port: si la dirección dada y
validación del WSDL es correcta entonces el campo se complementa
automáticamente -> Finish.
10. Cuando se ha terminado de generar los servicios Web con WSDL extendido de forma
exitosa es necesario publicar a los mismos con el servidor de aplicaciones configurado
para el proyecto (para esta tesis se utiliza el servidor GlassFish V2). El proceso de
publicación o despliegue de los servicios Web es el siguiente:
• Para la publicación exitosa de cada servicio primero se debe limpiar y construir el
proyecto realizando la siguiente secuencia de pasos: Clic derecho sobre el
proyecto -> Clean -> Clic derecho sobre el proyecto -> Clean and Build -> Clic
derecho sobre el proyecto -> Run -> Clic derecho sobre el proyecto -> Deploy. La
secuencia dada es para asegurarnos de una publicación correcta. Ahora se debe
probar que los servicios estén publicados, el proceso es el siguiente: Clic derecho
sobre el servicio -> Test Web Service -> se abrirá el navegador Web
predeterminado mostrando el WSDL extendido que describe al servicio que se
está probando (si el navegador muestra una lista de URLs seleccionar la que
corresponda al servicio que se desea probar para ver su descripción).
Capítulo 3: Banco de pruebas
52
3.8 JUDDI Este trabajo de tesis utiliza como registro de servicios la especificación UDDI utilizada por
[Ismael06]. El nombre de la especificación utilizada es jUDDI y ofrece libertad de uso sin la
necesidad de una licencia, cumple al 100% con el estándar UDDI versión 2.0 y nos
permite implementar un sistema de seguridad y autentificación genérico. Además jUDDI
está implementado en Java, lo que lo hace independiente de plataforma proporcionando
gran cantidad de documentación sobre sus componentes, mantenimiento y configuración.
JUDDI está soportada por una gran comunidad de desarrolladores, misma que mantiene
proyectos importantes como AXIS y Apache Tomcat [Tomc06].
El nodo UDDI para esta tesis ha sido implementado como una aplicación Web en
un servidor Tomcat 5.0 y utiliza una base de datos implementada en MySQL 1.4, la cual
contiene el conjunto de tablas que almacenan la descripción de los servicios según el
estándar UDDI versión 2.0. La implementación de la base de datos se muestra en la
Figura 12.
Figura 12. Implementación de la base de datos del nodo UDDI privado
Capítulo 3: Banco de pruebas
53
La Figura 13 muestra un esquema conceptual del estándar UDDI versión 2.0. Este
esquema solamente muestras las entidades más importantes, sus relaciones y
cardinalidad.
Figura 13. Esquema conceptual del estándar UDDI versión 2.0
Capítulo 4: WeSSQoS
54
CAPÍTULO 4: WeSSQoS
En este capítulo se presenta el sistema WeSSQoS. Este sistema utiliza como repositorio
de servicios al banco de pruebas creado en esta tesis y algunos monitores de servicios
proporcionados por el grupo GESSI de la UPC en Barcelona. Se describe de forma
general su arquitectura y sus principales componentes. También se describe el algoritmo
de ordenación que WeSSQoS utiliza para clasificar los servicios Web recuperados desde
los repositorios. En el Anexo B se especifican los parámetros de entrada/salida del
sistema en formato XML.
Capítulo 4: WeSSQoS
55
4.1 Descripción general de la arquitectura del sistema WeSSQoS El sistema WeSSQoS está estructurado mediante una arquitectura SOA compuesta por 3
elementos que se representan en la Figura 14 y se describen a continuación:
• QoSSelector. Servicio que permite obtener el ranking de los servicios Web
correspondientes a un dominio de software concreto según los NFR solicitados y
una lista de repositorios (QoSRepositoryProxys) de donde obtener la información
de QoS. Este servicio utiliza los diferentes QoSRepositoryProxys para obtener la
información de QoS de los servicios del dominio disponibles y se la proporciona,
junto con los NFR, al servicio QoSSelectionModel para obtener el ranking.
• QoSSelectionModel. Servicio que clasifica servicios Web de un dominio aplicando
un algoritmo de ordenación presentado en el Anexo A. Aunque en la actualidad se
utiliza sólo un QoSSelectionModel la arquitectura es lo suficientemente flexible
como para permitir utilizar otros adicionales que implementen diferentes algoritmos
de clasificación (uso del patrón de diseño Estrategia).
• QoSRepositoryProxy. Servicio que permite obtener los WS del dominio elegido
que residen en un repositorio, junto con su QoS. Inicialmente se han definido dos
subclases de QoSRepositoryProxy:
– Monitor. Subclase que se caracteriza por obtener la información de QoS en
tiempo de ejecución mediante técnicas de monitoreo. Esto implica que no
dispondrá de información referente a atributos de calidad estáticos como por
ejemplo el costo del servicio.
– DataBank. Subclase que se caracteriza por obtener la información de QoS del
proveedor. En el caso de atributos de calidad dinámicos, como por ejemplo el
tiempo de respuesta medio, el valor obtenido es el que el proveedor del servicio se
compromete a asegurar.
No se descarta la posibilidad de tener otras subclases de QoSRepositoryProxy,
por ejemplo un repositorio que use tanto datos dinámicos como estáticos para obtener la
QoS.
Capítulo 4: WeSSQoS
56
Figura 14. Arquitectura general de WeSSQoS
El caso de uso básico de WeSSQoS es el de la ordenación de WS de un dominio
de software, que se traduce en la utilización de la operación Rank4QoSRepository del
servicio QoSSelector. Otros casos de uso son: la utilización de la operación
GetServicesDataFromDomain del servicio QoSRepositoryProxy para que con la
información de QoS obtenida se aplique un algoritmo propio de clasificación; o la
utilización del servicio QoSSelectionModel con datos propios.
La Figura 15 muestra el diagrama de secuencia del caso de uso de ordenación de
WS. La operación Rank4QoSRepository tiene como parámetros de entrada una lista de
repositorios, una lista de NFR y un dominio de software, y devuelve el ranking, según los
NFR, de todos los WS del dominio sobre los que hay información en alguno de los
repositorios. Los diversos atributos y clases involucradas se presentan en la Figura 17.
• La lista de repositorios lProxies es una lista de QoSRepositoryProxy donde cada
uno de ellos se representa por su nombre, el endPoint que permite acceder al
servicio que obtiene su información (los endpoints corresponden a las direcciones
donde se encuentran los repositorios, tanto monitores como bancos de pruebas) y
su descripción.
Capítulo 4: WeSSQoS
57
• Cada requisito de la lista de NFR lReqs se representa por el nombre del atributo
de calidad, el valor que se requiere para el atributo, un booleano que indica si el
valor requerido se quiere minimizar (false) o maximizar (true) y otro booleano que
indica si el valor requerido es obligatorio (true) o no (false). Un valor es obligatorio
cuando no puede ser rebasado en caso de que se quiera minimizar o no puede ser
inferior en el caso de que se quiera maximizar. Por ejemplo, el cliente podría
querer minimizar el atributo coste de manera obligatoria con un máximo de 100
$/mes.
• El dominio se representa por un nombre lo que permite utilizar cualquier servicio
Web del mismo.
La operación Rank4QoSRepository realiza una llamada a la operación
GetServicesDataFromDomain de cada uno de los QoSRepositoryProxy (Databank o
Monitor), obteniendo todos los servicios del dominio que contiene cada repositorio junto
con toda la información de QoS disponible. Se utiliza el endPoint en el momento de crear
el objeto QoSRepositoryProxy. A medida que se van obteniendo las listas de los servicios,
se prepara una lista con la información de QoS de los requisitos solicitados.
En el caso de tener información de un mismo requisito en más de un repositorio,
se utiliza una política de priorización simple: se utiliza la información del primer repositorio
que aparece en la lista que tenga información del requisito (en otras palabras, el orden en
la lista de repositorios determina la prioridad para los atributos que se encuentran en más
de un repositorio). Una vez se dispone de la lista de servicios se utiliza la operación
QoSSelectionAlgorithm del servicio QoSSelectionMode para obtener el ranking a partir de
la lista de WS y la lista de requisitos. Finalmente, antes de devolver la lista como
resultado, se procesa la información de los servicios sobre los atributos obligatorios.
La Figura 16 resume las interfaces que han aparecido en el diagrama de
secuencia. Los servicios Monitor y DataBank ofrecen la interfaz de QoSRepositoryProxy
que puede ser ampliada según las necesidades, por ejemplo con operaciones para
registrar un servicio en el DataBank o con operaciones para monitorizar un servicio en el
Monitor. En la operación GetServicesDataFromDomain, se ha optado por obtener toda la
información de QoS en lugar de sólo los requisitos solicitados para aumentar la
reusabilidad del servicio QoSRepositoryProxy.
Capítulo 4: WeSSQoS
58
Figura 15. Diagrama de secuencia del caso de uso de ordenación de WS
Figura 16. Interfaces de los servicios de WeSSQoS
Capítulo 4: WeSSQoS
59
Figura 17. Modelo de datos utilizado en la arquitectura de WeSSQoS
Capítulo 4: WeSSQoS
60
4.2 Ejemplo del algoritmo de ordenación: distancia Euclidiana La arquitectura de WeSSQoS soporta la coexistencia de varios algoritmos de ordenación.
La versión actual del sistema implementa la interfaz QoSSelectionAlgorithm mediante la
función de utilidad Distancia Euclidiana para el proceso de ordenación como se presenta
en [Wang06] y que se resume en esta sección. Dados dos vectores A y B, en donde A=(a1,
a2, a3,…,an) y B=(b1, b2, b3, …,bn), la distancia euclidiana entre los dos vectores puede
calcularse de la siguiente manera:
En este contexto, la distancia euclidiana busca las distancias más cortas entre la
QoS de cada servicio candidato y los requisitos no funcionales que conforman la
especificación del consumidor. El algoritmo de ordenación resultante se representa en el
diagrama de flujo de la Figura 18. Se incluye también la consideración de la característica
de obligatoriedad que según el diagrama de la Figura 15, no forma parte del algoritmo
mismo, pero se ha integrado para dar una explicación más completa. A continuación se
describen las fases transitadas.
Figura 18. Algoritmo del módulo de selección
Capítulo 4: WeSSQoS
61
• Generación. En esta fase se construye una matriz QoS de tamaño n x k a partir de
la lista lReqts, donde n representa el número total de WS del dominio de software
en consideración (los WS candidatos) y k representa el número total de atributos
de calidad que aparecen en los NFR de la lista. Asimismo, la lista lReqs se
convierte en un vector qPc. Ambas estructuras deben normalizarse con el
propósito de compensar las diferentes unidades de medida entre las diferentes
propiedades de valores de QoS y para establecer los valores en el intervalo [0, 1].
Para ello, se necesita definir un vector NR = {nr1, nr2,…, nrk}. La normalización se
realiza utilizando las formulas 2 y 3. En el Anexo A se describe un ejemplo
detallado.
(2)
(3)
• Búsqueda. Una vez normalizadas la matriz QoS y el vector qPc, se evalúa la
Distancia Euclidiana entre cada servicio (filas de QoS) y los requisitos (vector qPc)
utilizando la ecuación (1). Para el ejemplo del Anexo A, se muestra el resultado del
proceso de búsqueda en la Tabla 2, segunda columna: WS4 tiene la mínima
Distancia Euclidiana que cumple con la mayoría de las especificaciones QoS del
cliente, por lo tanto parece el candidato a seleccionar, a la espera de analizar el
grado de cumplimiento de los requisitos obligatorios.
• Obligatoriedad. Posteriormente al proceso de ordenación, se procesa la
información sobre obligatoriedad. Suponiendo que en el ejemplo del Anexo A
todos los requisitos son obligatorios. En la Tabla 10 se muestra en la tercera
columna que WS4 cumple tan sólo 3 de los 6 requisitos, al igual que WS1,
mientras que WS2 y WS3 los cumplen todos. Si se combinan los resultados de la
clasificación por QoS y Obligatorio, la prioridad es diferente, por lo tanto, el cliente
debe decidir lo que mejor se adapte a sus necesidades.
Tabla 10. Resultado de la fase de búsqueda sobre el ejemplo Anexo A Servicio Distancia
Euclidiana Obligatorio Prioridad
QoS Prioridad
QoS/Obligatorio
WS1 1.0997 3/6 2 4 WS2 1.4339 6/6 4 2 WS3 1.4191 6/6 3 1 WS4 0.8725 3/6 1 3
Capítulo 4: WeSSQoS
62
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
WS1 1.0997 2 WS2 1.4339 4 WS3 1.4191 3 WS4 0.8725 1
Puesto que el servicio Web WS4 tiene la mínima distancia Euclidiana es el servicio que
será retornado al solicitante.
Anexo A: Análisis del modelo de selección basado en QoS
85
Diagrama de casos de uso
uc Use Case Model
ActorCliente
Selección por QoS
Extraer datos de repositorio
«include»
Figura 21. Diagrama de casos de uso para el modelo de selección basado en QoS
Descripción de actores
Actor: ActorCliente
Casos de Uso: Aplicar modelo QoS de selección (distanciaEuclidiana)
Descripción: Representa a cualquier entidad que actúe como cliente para aplicar
el modelo QoS de selección el cual selecciona servicios aplicando la
función de utilidad distancia Euclidiana. EL cliente debe enviar el
conjunto de sus requerimientos (atributo-valor).
Descripción de casos de uso
Nombre del Caso de
Uso 1. Extraer datos de repositorio
Actores primarios Selección por QoS
Actores secundarios ---
Descripción
Obtiene los datos de un conjunto de servicios Web de un mismo
dominio. La fuente de datos es cualquier repositorio donde se
encuentren servicios Web que contengan parámetros de calidad. Por
ejemplo: un banco de pruebas, un repositorio de algún monitor de
atributos de calidad, una base de datos, etc.
Anexo A: Análisis del modelo de selección basado en QoS
86
Requisitos especiales • Contar con un servidor de aplicaciones como Tomcat
• Los servicios a recuperar están clasificados en JUDDI
Pre-condiciones
• Se cuenta con al menos 1 servicio en el repositorio el cual integre
en su descripción o lugar específico los parámetros de calidad que
lo definen. Los datos recopilados del repositorio deben tener la
siguiente estructura: dominio, nombre del servicio, WSDL, punto de
acceso, descripción, parámetros de calidad<atributo-valor>. El
dominio debe ser igual para todos los servicios.
Post-condiciones
• Se obtendrá una lista de elementos los cuales serán todos los
servicios recopilados del repositorio con todos los datos
mencionados en las pre-condiciones.
Flujo básico
1. Se realiza la conexión al repositorio;
2. Se extraen los datos necesarios de cada servicio;
3. Obtener los parámetros de calidad en los WSDL de los servicios
Web;
4. Cargar la lista de datos que se retornará al modelo QoS de
selección con el formato especificado en pre-condiciones;
5. Regresar la lista de datos al modelo QoS de selección.
Flujo alterno
1. Se realiza la conexión al repositorio, si no se utiliza el banco de
pruebas y se utiliza otro repositorio. Él repositorio alterno debe
ser capaz de alimentar con todos los datos especificados a la
lista que se retornara al cliente.
Escenarios de
fracaso
1. Se extraen datos incorrectos o incompletos;
2. El servicio web de extracción de datos no está disponible;
3. Se integran datos de servicios de otros dominios;
4. No se envía la lista de datos con la estructura especificada.
Anexo A: Análisis del modelo de selección basado en QoS
87
Nombre del Caso de
Uso 2. Selección por QoS
Actores primarios ActorCliente
Actores secundarios ---
Descripción
Aplica el algoritmo de selección de servicios por QoS a partir de los
datos de un conjunto de servicios Web de un mismo dominio junto con
los requisitos del usuario.
Requisitos especiales • Contar con una fuente de datos que puede ser un banco de pruebas
o cualquier otro repositorio.
Pre-condiciones
• Se cuenta con al menos 1 servicio en el repositorio el cual integre
en su descripción o lugar específico los parámetros de calidad que
lo definen. Los datos recopilados del repositorio deben tener la
siguiente estructura: dominio, nombre del servicio, WSDL, punto de
acceso, descripción, parámetros de calidad<atributo-valor>. El
dominio debe ser igual para todos los servicios. Además se cuenta
con al menos un requisito del cliente.
Post-condiciones • Se obtendrá una lista priorizada de servicios Web
Flujo básico
1. Se crean las matrices de datos, una por datos del cliente y otra
por datos de los repositorios.
2. Se normalizan las matrices dadas
3. Se calcula la priorización de servicios mediante la distancia
euclidiana
4. Regresar la lista priorizada de servicios Web.
Flujo alterno 1. Si no hay datos de parte del cliente o de parte del repositorio el
algoritmo se calcula con valores igual a cero;
Escenarios de
fracaso
1. Se extraen datos incorrectos o incompletos;
2. El servicio web de extracción de datos no está disponible;
3. El repositorio no cuenta con ningún servicio Web;
4. Se integran datos de servicios de otros dominios;
5. No se envía la lista de datos con la estructura especificada.
6. El servicio Web del algoritmo dejo de funcionar
Anexo A: Análisis del modelo de selección basado en QoS
88
Conclusiones sobre el algoritmo basado en QoS El algoritmo de selección presenta problemas tales como: el caso de una división por
cero. Al aplicar una normalización por minimización o maximización se puede dividir por
cero sí y sólo si qPivmax sea igual a qPivmin. Por ejemplo:
QPc= [0.9, 20, 50, 0.9, 1, 200] QoS =
Norm (qPiv)=
Como se puede observar en QPc existe el valor 0.9 al igual que en la matriz QoS y
si estos valores fueran mínimos y máximos a la vez entonces al aplicar la formula de
minimización o maximización el divisor será 0 y causará un error. El problema se presenta
sí y sólo si qPivmax es exactamente igual a qPivmin. Para resolver el problema se puede
realizar una verificación de datos antes de que se aplique el algoritmo específicamente en
el proceso de normalización.
Otro caso que se puede presentar es el de obtener resultados negativos en el
momento de aplicar la normalización de datos. Si se requiere minimizar el resultado
puede ser negativo sí y sólo si qPiv sea mayor que qPivmax o que qPivmin sea mayor a
qPivmax.
QPc= [0.9, 20, 50, 0.9, 1, 200] Qos =
Norm (qPiv)=
Para que qPiv pueda ser mayor a qPivmax no se toman en cuenta en el cálculo los
valores de QPc, es decir, al aplicar la normalización de datos solo se toman los valores de
la matriz QoS y no los del vector QPc. La solución al problema es tomar en cuenta los
valores de QPc y si se incluyen estos valores entonces qPivmin no podrá ser mayor que
qPivmax.
Anexo B: Parámetros del sistema
89
ANEXO B: PARÁMETROS DEL SISTEMA
Las siguientes líneas son los parámetros que se utilizan en el sistema WeSSQoS, se
muestran en fragmentos de código XML:
1. Servicio -> QoSSelector
Operación: Rank4QoSRepository
Parámetros de entrada:
oListRepositoryProxy: list <RepositoryProxy>
oListStakeholderRequirements: list <StakeholderRequirements>
domain: String
Respuesta:
oListServicesDataPriorityResult: list <ServiceDataPriorityResult>
Los atributos de los tipos RepositoryProxy, StakeholderRequirements,
ServiceDataPriorityResult,… se pueden ver en el WSDL (apartado Other Types).
Anexo B: Parámetros del sistema
90
<!-- REQUEST/RESPONSE TYPES -->
<xs:element name="Rank4QoSRepositoryRequest">
<xs:complexType>
<xs:sequence>
<xs:element name="oListRepositoryProxy" type="tns:RepositoryProxy"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="oListStakeholderRequirements"
type="tns:StakeholderRequirements" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="domain" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<!-- Respuesta del servicio -->
<xs:element name="Rank4QoSRepositoryResponse">
<xs:complexType>
<xs:sequence>
<xs:element name="oListServicesDataPriorityResult"
type="tns:ServiceDataPriorityResult" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<!-- OTHER TYPES -->
<xs:complexType name="RepositoryProxy">
<xs:sequence>
<xs:element name="name" type="xs:string"/>
<xs:element name="endPoint" type="xs:string"/>
<xs:element name="description" type="xs:string"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="StakeholderRequirements">
<xs:sequence>
<xs:element name="metric" type="xs:string"/>
<xs:element name="value" type="xs:string"/>
<xs:element name="maxmin" type="xs:boolean"/>
<xs:element name="mandatory" type="xs:boolean"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="ServiceDataPriorityResult">
<xs:sequence>
<xs:element name="name" type="xs:string"/>
<xs:element name="wsdl" type="xs:string"/>
<xs:element name="endPoint" type="xs:string"/>
<xs:element name="description" type="xs:string"/>
<xs:element name="euclidianDistance" type="xs:double"/>
<xs:element name="incrementMandatory" type="xs:int"/>
<xs:element name="metricValuesMand"
type="tns:MetricValueMand" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
Anexo B: Parámetros del sistema
91
<xs:complexType name="MetricValueMand">
<xs:sequence>
<xs:element name="metric" type="xs:string"/>
<xs:element name="value" type="xs:string"/>
<xs:element name="mandatory" type="xs:boolean"/>
</xs:sequence>
</xs:complexType>
2. Servicio -> RepositoryProxy
Operación: GetServicesDataFromDomain
Parámetros de entrada:
domain: String Respuesta:
servicesData: list <ServiceData>
Los atributos del tipo ServiceData,… se pueden ver en el WSDL (apartado Types
ServicesData).
<xs:element name="GetServicesDataFromDomainRequest">
<xs:complexType>
<xs:sequence>
<xs:element name="domain" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="GetServicesDataFromDomainResponse">
<xs:complexType>
<xs:sequence>
<xs:element name="servicesData" type="tns:ServiceData"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
//Types ServicesData
<xs:complexType name="ServiceData">
<xs:sequence>
<xs:element name="name" type="xs:string"/>
<xs:element name="wsdl" type="xs:string"/>
Anexo B: Parámetros del sistema
92
<xs:element name="endPoint" type="xs:string"/>
<xs:element name="description" type="xs:string"/>
<xs:element name="metricValues" type="tns:MetricValue"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="MetricValue">
<xs:sequence>
<xs:element name="metric" type="xs:string"/>
<xs:element name="value" type="xs:string"/>
</xs:sequence>
</xs:complexType>
3. Servicio -> QoSSelectionModel
Operación: QoSSelectionAlgorithm
Parámetros de entrada:
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 -->
<xs:element name="QoSSelectionAlgorithmRequest">
<xs:complexType>
<xs:sequence>
<xs:element name="oListServicesDataForModel"
type="tns:ServiceDataForModel" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="oListStakeholderRequirementsForModel"
type="tns:StakeholderRequirementsForModel" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<!-- Respuesta del servicio -->
<xs:element name="QoSSelectionAlgorithmResponse">
<xs:complexType>
<xs:sequence>
Anexo B: Parámetros del sistema
93
<xs:element name="oListServicesDataPriorityResultByModel"
type="tns:ServiceDataPriorityResultByModel" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<!-- OTHER TYPES -->
<xs:complexType name="ServiceDataForModel">
<xs:sequence>
<xs:element name="name" type="xs:string"/>
<xs:element name="wsdl" type="xs:string"/>
<xs:element name="endPoint" type="xs:string"/>
<xs:element name="description" type="xs:string"/>
<xs:element name="metricValuesForModel"
type="tns:MetricValueForModel" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="MetricValueForModel">
<xs:sequence>
<xs:element name="metric" type="xs:string"/>
<xs:element name="value" type="xs:string"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="StakeholderRequirementsForModel">
<xs:sequence>
<xs:element name="metric" type="xs:string"/>
<xs:element name="value" type="xs:string"/>
<xs:element name="maxmin" type="xs:boolean"/>
<xs:element name="mandatory" type="xs:boolean"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="ServiceDataPriorityResultByModel">
<xs:sequence>
<xs:element name="name" type="xs:string"/>
<xs:element name="wsdl" type="xs:string"/>
<xs:element name="endPoint" type="xs:string"/>
<xs:element name="description" type="xs:string"/>
<xs:element name="euclidianDistance" type="xs:double"/>
<xs:element name="incrementMandatory" type="xs:int"/>
<xs:element name="metricValuesByModel" type="tns:MetricValueByModel"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="MetricValueByModel">
<xs:sequence>
<xs:element name="metric" type="xs:string"/>
<xs:element name="value" type="xs:string"/>
<xs:element name="mandatary" type="xs:boolean"/>
</xs:sequence>
</xs:complexType>
Referencias
94
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.