QoSPref

What is it?

QoSPref is a Java library for ranking web services based on non-functional properties such as quality of service (QoS). QoSPref allows users to express trade-offs between the various non-functional properties in a simple, but flexible manner. It uses an intuitive notation inspired by the way people reason about their preferences.

A detailed description of the preference notation and of the method used by QoSPref to rank web services can be found in this paper:

I strongly urge you to read this paper before starting to use QoSPref.

 

A short, informal presentation for the impatient

I know you didn't read the paper and I'm really mad at you. But still, I will briefly explain you the notation used to express non-functional preferences.

Let's suppose you write an application that shows the state of an industrial process by regularly displaying charts on a monitor. Instead of drawing the charts itself, your application relies on chart generation web services. At any moment, your application can retrieve a list of the currently available chart generation services and of their non-functional properties. Then, a service broker that uses the QoSPref library selects the chart generation service that best fits your preferences.

In order to express your preferences, you must first declare the relevant non-functional properties. Suppose these are: the response time, the cost per chart and the number of colors of the image delivered by the service. You can describe them as follows:

    quantities {
        responseTime: real,
        cost : real,
        colors : integer
    }

Now, you may specify some hard constraints, which must be satisfied by all candidate web services. For example:

    constraints {
        cost < 10,
        responseTime < 10
    }

Finally, you specify your preferences, in the order of their importance. For example:

    preferences {
        responseTime,
        colors : high,
        cost
    }

By default, it is assumed that lower values are preferred for a property. Since this is not true for the number of colors, it must be explicitly stated by using the keyword 'high'. Using the above preference specification, QoSPref will compare two services by starting with their responseTime. If one service has a better value of this property, it will be preferred. If both services have the same responseTime, the comparison will continue with their colors property and, if there is still no difference, with their cost. This is called 'lexicographic comparison'. It is simple, but not suitable for more complex scenarios.

Let us suppose that the monitor used to display the charts supports 65536 colors. Therefore, from our point of view, a web service that generates charts with, say, 16 million colors is no better than one generating charts with only 65536 colors. On the other hand, a web service that generates charts with only 256 colors is clearly worse and you want to avoid that, even if this means choosing a service with a higher responseTime. Therefore, you have to specify that, when comparing two services, the number of colors becomes more important than the responseTime, if at least one of the services generates charts with less than 65536 colors. You do this by using a conditional preference rule:

    preferences {
        [AT_LEAST_ONE(colors < 65536)] colors: high,
        responseTime,
        colors : high,
        cost
    }

Conditions are placed between brackets and are constructed using one of the unary preferential operators shown in the table below.

The first three operators take as argument a boolean expression, which is evaluated twice, once for each of the web services to be compared. The two resulting boolean values are combined using the operator (OR, XOR, or AND) associated with the given preference operator. The preference operator DIFF takes as argument a QoS attribute and returns the modulus of the difference of its corresponding values from the two web services compared.

AT_LEAST_ONE is the default operator and it can be omitted. You can therefore specify your preferences like this:

    preferences {
        [colors < 65536] colors: high,
        responseTime,
        colors : high,
        cost
    }

Because in the current preference specification cost is the least important property, you may end up paying a fortune for a small increase in service quality. Therefore, you decide that it would be more reasonable to choose a higher quality service only if its price is at most 2$ higher than the price of the other service. Otherwise, cost should be considered the most important property. The preference specification looks like this:

    preferences {
        [DIFF(cost) > 2] cost,
        [colors < 65536] colors: high,
        responseTime,
        colors : high,
        cost
    }

Finally, suppose that your application updates the image on the screen at 5-second intervals. If the web service has not been able to provide a new chart in the interval between two updates, your application displays only a big red solid rectangle. This makes your customers angry. Very angry. Avoiding this situation is of paramount importance. Let us note that in this scenario responseTime should be considered the most important property only when exactly one of the two web services compared has a value higher than 5 seconds for this attribute. If, for example, both web services considered are able to provide the chart in less than 5 seconds, we don't have to worry about missed updates. Conversely, if both services compared have a responseTime higher than 5 seconds, an update of the monitor will be inevitably skipped, therefore the actual value of this attribute is no longer of critical importance. Let's add a new preference rule that reflects our needs:

    preferences {
        [EXACTLY_ONE(responseTime > 5)] responseTime,
        [DIFF(cost) > 2] cost,
        [colors < 65536] colors: high,
        responseTime,
        colors : high,
        cost
    }

Until now, we have discussed only about comparing two web services at a time. You may think that ranking a set of several services can be easily done by making pairwise comparisons of these services. But is it really so? Let us consider the following 3 candidate web services:

Performing pairwise comparisons in accordance with our final preference specification, we get the following results:
    - WS1 is preferred to WS2
    - WS2 is preferred to WS3
    - WS3 is preferred to WS1

This is a cyclic relation, but QoSPref is still able to rank the web services in a way that best fits the user preferences. How does it make it? I'm not gonna tell you. Now, read the damn paper!

QoSPref offers a GUI that allows you to specify QoS preferences and configure a set of candidate web services that will be ranked accordingly.

You can execute the GUI as applet or as stand-alone application. .

Here is a snapshot of the QoSPref Gui:

The preference specification can be introduced in the top left editing area. On start, the application loads an example specification, which is very similar to the one presented in the short presentation. It also loads the values of the QoS attributes of 5 candidate web services. These values can be configured in the bottom left panel.

In order to know which QoS attributes are relevant for your services, the application must first parse the preference specification. Therefore, each time you change the preference specification, you must press the "Generate" button, in order to trigger the parsing. As a result, the list of candidate services will be reset, the old editing fields for QoS attributes will be deleted and new ones wil be created, in accordance with the new preference specification.

At the same time, the application generates the Java bytecode of the methods used to perform the pairwise comparison of services. The "Java" tab in the right-side panel displays the source code equivalent to the generated bytecode. This source code is not used by the application, but it may help you to understand how the comparisons are performed for your preference specification.

The ranking of the candidate services is triggered by pressing the "Compare" button. The "Output" tab shows the results.