WeSSQoS: A Configurable SOA System for Quality-aware Web Service Selection

Web Services (WS) have become one the most used technologies nowadays in software systems. Among the challenges when integrating WS in a given system, requirements-driven selection occupies a prominent place. A comprehensive selection process needs to check compliance of Non-Functional Requirements (NFR), which can be assessed by analysing WS Quality of Service (QoS). In this paper, we describe the WeSSQoS system that aims at ranking available WS based on the comparison of their QoS and the stated NFRs. WeSSQoS is designed as an open service-oriented architecture that hosts a configurable portfolio of normalization and ranking algorithms that can be selected by the engineer when starting a selection process. WS’ QoS can be obtained either from a static, WSDL-like description, or computed dynamically through monitoring techniques. WeSSQoS is designed to work over multiple WS repositories and QoS sources. The impact of having a portfolio of different normalization and ranking algorithms is illustrated with an example.

💡 Research Summary

The paper presents WeSSQoS, a configurable Service‑Oriented Architecture (SOA) framework designed to rank and select Web Services (WS) based on their Quality of Service (QoS) attributes in relation to stakeholder‑specified Non‑Functional Requirements (NFRs). The authors begin by highlighting the proliferation of WS in modern software ecosystems and the consequent challenge of choosing the most appropriate service when many alternatives exist. While functional compatibility can be addressed through domain matching, the decisive factor often lies in non‑functional qualities such as cost, response time, and availability, which are captured by QoS metrics and typically expressed in Service Level Agreements (SLAs).

A comprehensive literature review (Table I) classifies existing QoS‑based WS selection frameworks according to architectural style (Component‑Based Architecture, SOA, or hybrid), supported QoS attributes, data sources (static declarations vs. dynamic monitoring), ability to employ multiple ranking algorithms, support for multiple repositories, and availability of a prototype. The authors note that most prior work relies on a single normalization and ranking method, lacks true SOA integration, or does not combine data from heterogeneous repositories.

WeSSQoS addresses these gaps by defining a three‑stage selection pipeline: (1) Normalization, (2) Ranking, and (3) Priority Evaluation. Input consists of a QoS matrix (WSlist) containing k candidate services and n QoS attributes, and an NFR vector (lreqs) that encodes for each attribute the required value, a flag indicating whether the attribute should be minimized or maximized, and a flag indicating whether the requirement is mandatory.

During normalization, both WSlist and lreqs are projected onto the interval