Qais

T4 - Case study: the ASK system

The ASK system is a communication software product that acts as a mediator between service consumers and service providers, for instance, connecting rescue institutions and professional volunteers. The connection established by the ASK system is provided by mechanisms for matching users requiring information or services with potential suppliers. For this purpose, the matching mechanisms use the profiles and availability offered by people who provide or require services.

The main goal of the ASK system is to do the matching in an efficient way. To achieve that, the system collects feedback on the quality of services after the connection. Such feedback is used to decide better connections for the subsequent requests of the same type. In addition, the system uses self-learning and self-organizing mechanisms by continuously adapting to users' preferences and available resources.

When people request a certain service from specialists or service providers, the ASK system attempts to select the best service provider. This selection is based on the rating of the knowledge and the skills of service providers who are available at that moment. This rating, in turn, is based on the feedback on the quality of services offered by the service providers.

Moreover, the occurrence of events can follow either regular schedules or ad-hoc schedules. The ASK system deals with both of the situations while satisfying the constraints and the purposes of users' requests.

So far, we have abstractly described the ASK system as an agent to provide the connection between service providers and service consumers in an ``efficient'' way. It should be noted that at each time not only one connection is handled. From the architecture perspective, the ASK system is designed as a hierarchical modular system, i.e., it is divided into a number of components taking account into higher level functionalities, and each component is also divided into a number of threads taking into account lower level functionalities. In order to handle massive connections, the components need to have multiple threads that have the same functionalities so that the connections are handled concurrently. In such cases, to provide efficient connections for all users is not trivial.

What is meant by efficiency can be defined and calculated in various ways, i.e., according to the various constraints of quality of services. The result of this calculation, so-called performance evaluation, is better and better when a system has more and more resources. However, in reality, resources are limited. Thus, it is important to show how to obtain the best performance, or more practically a reasonable performance, using limited resources. For instance, consider the call center example from the summary. It is important to keep the waiting time of customers under a reasonable amount of time. Since the number of operators that the call center can employ is limited, they need to be allocated according to the rate of calls during the day. In order to do this, a quantitative evaluation of the number of calls and waiting time can help.

The ASK system has been modeled in Reo. Using that model, extended with rates extracted from the logs of the system, we intend to instantiate the notions defined in T1 and T2 in order to answer questions about resource allocation (such as the questions in the summary). In order to do that we will also extend the Reo model with ``ideal'' rates, i.e. we will create a reference model which we will compare with the actual running model. Furthermore, the notion of distance, from T2, can be used to help improving the ASK system service matching functionality. We will implement this together with Almende.

Main contributions:

• An ``ideal'' Reo model of the ASK system, built in collaboration with the engineers at Almende.
• A Reo model of several running instances of the ASK system. This will imply statistical analysis of the logs of the system in order to extract the rates.
• Analysis of several desirable properties of the system, from which several guidelines to optimize resource allocation should come out.

Research team: BI 6M

Deliverables: case study paper in a mainstream conference (such as WS-FM or FMOODS); a workshop paper; integration of the tool developed in T3 and the ECT tools (this is the toolset wherein Reo models can be defined) and one PhD? thesis (Alejandro Sanchez).