The Gross Interest: Service Popularity Aggregation

The Gross Interest: Service Popularity Aggregation

Mohamed Hamdy (Ain Shams Universit, Egypt) and Birgitta König-Ries (Friedrich-Schiller-University Jena, Germany)
DOI: 10.4018/978-1-61350-432-1.ch014


Service popularity, e.g., how often a service is requested, can be an important non-functional property determining the life-cycle of a service. To capture it, the requesting behavior of clients needs to be modeled. In this work, we introduce and discuss: the importance of the service popularity, a generalized requesting model that can capture the requesting behavior of clients, a service popularity measure called “Gross Interest,” and a Gross Interest quantification method. Two extremely different sets of specifications for the proposed generalized requesting model which produce two different Gross Interest scenarios (rich and poor scenarios) are introduced and quantified. As an application example for the service popularity, we show a service replication protocol for Mobile Ad Hoc Networks (MANETs) which realizes and employs service popularity in its replication decisions.
Chapter Preview


Realizing distributed applications based on Service Oriented Architectures (SOA) became recently very popular. Merging SOA with the up-growing semantic technologies enabled new dimensions of automation for the related core building blocks of SOA like service discovery, ranking, composition and execution. Selecting a suitable atomic service or a set of services is usually based on the service ranking process. Service ranking is an important process which utilizes the service descriptions to determine an index of relevancy for a set of services regarding a service request. The ranking process generally uses two main categories of service description attributes which are functional and non-functional. While the functional and behavioral attributes describe respectively what the service does and how its functionalities are achieved, the non-functional attributes describe the restrictions and constraints on the provided service functionalities (Toma et al., 2007).

Matching a service offer for a specific service request is dependent on the deployed service ranking and matchmaking process. The early service ranking and matchmaking approaches focused only on the functional and behavioral attributes. Recently, a new generation of ranking approaches is starting to include the non-functional attributes in their decisions. Finding a way to balance the impacts of the functional and non-functional attributes is the key for achieving a better service ranking and more accurate matches (Hamdy et al., 2007).

Even if the descriptions of a specified service include the functional and typical non-functional attributes, they miss an important category of attributes, namely those aggregated attributes that the service can accumulate during its life time. This lack in descriptions can not be complemented or configured by an initial service offer. In fact, attributes like service popularity and trust represent an important set of attributes that can not originally (or at any other time) be specified by the service provider. Instead of that, it is accumulated, for example, from its clients requesting behavior.

The aggregated attributes represent a very important category of non-functional attributes which can not be easily described. From a provider perspective, the service popularity plays a great role. It is needed for a service provider in order to decide when it is supposed to enhance, replace or shut down a specified service. From a client perspective, for example, service popularity plays an important role in supporting the shown trust attributes of the service provider. Moreover, considering a set of competing services and providers, having such a computed service popularity attributes supports deploying better versions of services.

The concepts of service ranking and popularity may seem overlapping, but, imagine a distributed system with a SOA enabled application in which an un-interesting (i.e., unpopular) service is deployed with a unique functionality. Should there ever be any request for this functionality by a system participant, this service will perfectly match, but this happens rarely. On the other hand, this service needs to be considered by the SOA core mechanisms like discovery and matchmaking adding to the effort required to perform them. Moreover, in some environments like unstable and mobile networks, this will be even more extreme, as there, services will frequently need to be replicated to ensure availability as required in many cases and applications. Replicating a service that is basically never used is clearly a waste of resources. From another perspective, both service ranking and popularity may be overlapping, if the service popularity reflects better functional, behavioral and non-functional service facilities. In that case, the better service offers will be more popular. In these cases, the service popularity that is being computed during the service operation will be not only be affected by the good attributes of the offered service, but will also prove these offers.

Since the aggregated attributes, namely service popularity, are absent in the service offer, the current service ranking and matchmaking approaches can not include them in the service selection. So, this missing integration between the service popularity and selection is required to overcome.

Key Terms in this Chapter

Requirements’ Index: Presents the possibility to create new meanings for the service popularity by combining it with other functional and non-functional service attributes.

Service Popularity: An important non-functional property determining the life-cycle of a service carachterising how often a service is requested.

Gross Interest: The aggregated interest towards a specified service within a certain time.

Generalized Requesting Model: A model of clear and numeric based attributes to describe the requesting behavior of the clients.

Service Content: The collection of services (and their replicas if applicable and as required) to provide the required functionalities (in the interest scope of the network participants) of a specified network at a specified time.

Complete Chapter List

Search this Book: