cenidet Oscar Jair... · cenidet Centro Nacional de Investigación y Desarrollo Tecnológico Departamento de Ciencias Computacionales TESIS DE MAESTRÍA EN CIENCIAS EN CIENCIAS

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.


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.


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


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.


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


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).


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


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


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).


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


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.


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.


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.


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


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


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.


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.


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].


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.


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).


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


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


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


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 *


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


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].


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


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.


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.


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.


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


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.


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)


mínima

Mide cual es el tiempo de ejecución mínimo en milisegundos que un servicio Web toma

para ejecutar un trabajo


máxima

Mide cual es el tiempo de ejecución máximo en milisegundos que un servicio Web toma

para ejecutar un trabajo


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.


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


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.


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


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


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.


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.


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:


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:


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">


</part>

<part name="AverageExecutionTime" element="tns:QoSAtributos">


49


</part>

<part name="MaximumResponseTime" element="tns:QoSAtributos">


</part>

<part name="AverageResponseTime" element="tns:QoSAtributos">


</part>

<part name="FaultFactor" element="tns:QoSAtributos">

<documentation>0.4</documentation>

</part>

<part name="ResultAccuracyFactor" element="tns:QoSAtributos">


</part>

<part name="Cost" element="tns:QoSAtributos">


</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"?>



<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">


</part>

<part name="MaximumExecutionTime" element="tns:QoSAtributos">


50


</part>

<part name="AverageExecutionTime" element="tns:QoSAtributos">


</part>

<part name="MaximumResponseTime" element="tns:QoSAtributos">


</part>

<part name="AverageResponseTime" element="tns:QoSAtributos">


</part>

<part name="FaultFactor" element="tns:QoSAtributos">


</part>

<part name="ResultAccuracyFactor" element="tns:QoSAtributos">


</part>

<part name="Cost" element="tns:QoSAtributos">


</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>


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).


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


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.


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.


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.


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.


58

Figura 15. Diagrama de secuencia del caso de uso de ordenación de WS

Figura 16. Interfaces de los servicios de WeSSQoS


59

Figura 17. Modelo de datos utilizado en la arquitectura de 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


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


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


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


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


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.


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


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:


descriptivo y la dirección del monitor especificado.


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:


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


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


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




descriptivo, la dirección del monitor y banco de pruebas especificado.



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:



MaximumExecutionTime 35 True False


MaximumResponseTime 20 True False


FaultFactor 0.5 True False


70


Cost 160 True False


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).










encuentran los 8 atributos. A continuación se especifican las entradas de esta

sección:


71









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).






72






encuentran 7 atributos. A continuación se especifican las entradas de esta

sección:









Cost 160 True False



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


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).









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:









Cost 160 True False



monitor, no contiene algunos servicios que contiene el banco; Sí habrá combinación de


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).









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:





75





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.


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


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.


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:


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.75 (aplicando formula 3)

Norm (q ) = - = – = = 1 (aplicando formula 3)


QPc Normalizada.

QPc = [0.9, 0.0, 0.17, 0.75, 1.0, 0.75]

2.- Normalizar la matriz QoS.

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


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


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.


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.


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.


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


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).


90



<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>



<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>



<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="wsdl" 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>


91

<xs:complexType name="MetricValueMand">

<xs:sequence>




</xs:sequence>

</xs:complexType>

2. Servicio -> RepositoryProxy

Operación: GetServicesDataFromDomain


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"


</xs:sequence>

</xs:complexType>

</xs:element>

//Types ServicesData

<xs:complexType name="ServiceData">

<xs:sequence>




92



<xs:element name="metricValues" type="tns:MetricValue"


</xs:sequence>

</xs:complexType>

<xs:complexType name="MetricValue">

<xs:sequence>



</xs:sequence>

</xs:complexType>

3. Servicio -> QoSSelectionModel

Operación: QoSSelectionAlgorithm


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). 

<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"


</xs:sequence>

</xs:complexType>

</xs:element>



<xs:element name="QoSSelectionAlgorithmResponse">

<xs:complexType>

<xs:sequence>


93

<xs:element name="oListServicesDataPriorityResultByModel"

type="tns:ServiceDataPriorityResultByModel" minOccurs="0"


</xs:sequence>

</xs:complexType>

</xs:element>



<xs:complexType name="ServiceDataForModel">

<xs:sequence>





<xs:element name="metricValuesForModel"

type="tns:MetricValueForModel" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

</xs:complexType>

<xs:complexType name="MetricValueForModel">

<xs:sequence>



</xs:sequence>

</xs:complexType>

<xs:complexType name="StakeholderRequirementsForModel">

<xs:sequence>



<xs:element name="maxmin" type="xs:boolean"/>


</xs:sequence>

</xs:complexType>

<xs:complexType name="ServiceDataPriorityResultByModel">

<xs:sequence>





<xs:element name="euclidianDistance" type="xs:double"/>

<xs:element name="incrementMandatory" type="xs:int"/>

<xs:element name="metricValuesByModel" type="tns:MetricValueByModel"


</xs:sequence>

</xs:complexType>

<xs:complexType name="MetricValueByModel">

<xs:sequence>



<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.

Documents

cenidet Oscar Jair... · cenidet Centro Nacional de Investigación y Desarrollo Tecnológico Departamento de Ciencias Computacionales TESIS DE MAESTRÍA EN CIENCIAS EN CIENCIAS