PDF de programación - WeSSQoS: Un Sistema SOA para la Selección de Servicios Web según su Calidad

WeSSQoS: Un Sistema SOA para la Selección de

Servicios Web según su Calidad

Oscar Cabrera1,2, Marc Oriol1, Lidia López1, Xavier Franch1, Jordi Marco1,

Olivia Fragoso2, René Santaolaya2



1 Universitat Politècnica de Catalunya (UPC)
c/Jordi Girona, 1-3, E-08034 Barcelona, Spain
{moriol, llopez, franch, jmarco}@lsi.upc.edu

2 Centro Nacional de Investigación y Desarrollo Tecnológico (CENIDET)

Interior Internado Palmira S/N, Col. Palmira, CP 62490, Cuernavaca, Morelos, México

{cabrera_bejar07, ofragoso, rene}@cenidet.edu.mx

Resumen. Los Servicios Web (WS) se han convertido en una tecnología
altamente utilizada en el desarrollo de sistemas software. Una de sus
problemáticas más importantes es la selección de los WS más apropiados para
satisfacer los requisitos del sistema. Si consideramos los requisitos no
funcionales (NFR), la calidad de servicio de los WS contiene la información
necesaria para analizar dicha satisfacción. En este artículo se describe el sistema
WeSSQoS para la ordenación de WS según su grado de satisfacción de los
NFR, calculable a partir de la calidad de servicio de dichos WS, que puede
declararse en el WSDL mismo o bien calcularse dinámicamente mediante
monitorización. Esta información acerca de la calidad puede provenir de
diversas fuentes (diferentes repositorios WSDL, diferentes monitores, etc.). La
arquitectura de WeSSQoS permite la coexistencia de diversos algoritmos de
ordenación de los WS, si bien en este artículo nos centramos en uno de ellos
que usa la distancia euclidiana como criterio de ordenación.
Palabras clave: Arquitecturas Orientadas a Servicios (SOA), Selección de
Servicios Web, Calidad de Servicio (QoS), Requisitos no Funcionales (NFR).

1 Introducción

Los Servicios Web (WS1) [1] 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.

Los WS 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, ora accesibles
separadamente, ora residentes en catálogos. Si bien tal proliferación incrementa las



1 En este artículo se utilizan abreviaturas de los términos ingleses por su mayor difusión.

2

posibilidades de encontrar WS ya existentes para satisfacer una necesidad dada, al
mismo tiempo provoca diversas problemáticas y entre ellas destacamos precisamente
el problema de la selección del WS más apropiado para un contexto de uso [2], 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, consideramos la distinción clásica entre
requisitos funcionales y requisitos no funcionales [3]. 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: coste 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.

Este trabajo de investigación se centra en la ordenación de WS pertenecientes a un
mismo dominio de software (que supondremos que se ha determinado previamente en
función de los requisitos funcionales) 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 concreto, en este trabajo se presenta WeSSQoS (Web Service Selection based
on Quality of Service), un sistema para la selección de WS basado en QoS. WeSSQoS
propone una arquitectura SOA abierta que acoge en su núcleo uno o más algoritmos
de cómputo de la adecuación de un WS respecto a los NFR; a modo de ejemplo, en
este artículo utilizamos un algoritmo que mide la adecuación en términos de distancia
euclidiana. Los NFR se expresan mediante expresiones formuladas sobre atributos de
calidad cualesquiera; a modo de ejemplo, en este artículo utilizamos 10 atributos
provenientes del modelo de calidad propuesto en [4]. 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 WS
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, o bien puede monitorizarse el
comportamiento del WS, obteniendo pues la QoS real del WS. En este sentido,
compartimos la visión de [5] que propone que sólo los atributos estáticos (p.e., coste)
deberían ser definidos a priori mientras que los atributos dinámicos (p.e.,
disponibilidad) deberían ser obtenidos mediante un sistema de monitorización.

El resto del artículo se organiza como sigue. En la Sección 2 clasificamos algunos
sistemas de selección de WS basados en QoS según los criterios citados arriba. En la
Sección 3 presentamos la arquitectura de WeSSQoS. En la Sección 4 describimos el
algoritmo de ránking de WS que estamos utilizando actualmente. En la Sección 5 pre-
sentamos los detalles de implementación y en la Sección 6 describimos los juegos de
pruebas utilizados. En la Sección 7 presentamos las conclusiones y el trabajo futuro.

2 Trabajo Relacionado

3

Existen diversas propuestas de marcos de ordenación y/o selección de WS según su
QoS. En la Tabla 1 se presentan algunas de estas propuestas, comparadas según los
criterios siguientes:

 Estilo arquitectónico. Arquitectura de la implementación. Encontramos
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.
Destacamos 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).

 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., cuyo framework obtiene la lista de servicios web de
distintos UDDIs para almacenándolos en su 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 en
los artículos, e incluso algunos dispongan de página web como QCWS, solo
hemos encontrado la herramienta disponible en la propuesta de Al-Masri et al.

Tabla 1. Tabla comparativa de los diversos sistemas considerados

Propuesta

Estilo

arquitectónico

Atributos

Datos QoS

Multi-

algoritmo

Multi-

repositorio

Prototipo
disponible

Al-Masri et al. [5]

QCWS [6, 7]

Liu et al.[2]

QoS-IC [8]

CBA

CBA

CBA

CBA+SOA

Wang et al.[9]

Sólo algoritmo

Maximilien et al. [10]

Hu et al. [11]

SOA
SOA

4 dinámicos
2 estáticos

Estáticos definidos y

dinámicos

monitorizados

No

4 din. + 1 est.

Definidos

Sí, cerrado

1 din. + 5est.

5 din. + 1 est.
Configurable
1 din. + 5 est.
Config. 3 din.
3 din. + 2 est.

Est. definidos y din.

monitorizados

Definidos

Definidos

Monitorizados

Definidos

No

No

No

No
No

Sí

No

No

No

No

No
No

Sí

No

No

No

No

No
No

4

3. Descripción General de la Arquitectura del Sistema WeSSQoS

El sistema WeSSQoS está estructurado mediante una arquitectura SOA compuesta