Considering Quality of a Service in an Intentional Approach

Considering Quality of a Service in an Intentional Approach

Assia Ait-Ali-Slimane (Université Paris1 Panthéon Sorbonne, France), Manuele Kirsch-Pinheiro (Université Paris1 Panthéon Sorbonne, France) and Carine Souveyet (Université Paris1 Panthéon Sorbonne, France)
DOI: 10.4018/978-1-61350-432-1.ch015
OnDemand PDF Download:
$30.00
List Price: $37.50

Abstract

The success of service-based applications is based on service technologies such as Web services. Nevertheless, the benefits of the Service-Oriented Architecture (SOA) remain mainly at the software level, since business people are often unable to fully exploit its benefits due to their unfamiliarity with such software level technology. The intentional Service-Oriented Architecture (iSOA) suggests a move from the function-driven SOA to intention-driven SOA in order to provide service description understandable by business practitioners. However, such transposition from business to implementation level should also consider Quality of Service (QoS) aspects. In this paper, we propose modeling the Quality of intentional Service (QoiS) by introducing the quality goals and their qualitative and quantitative evaluation. We also propose populating the intentional service registry of the iSOA architecture with the QoiS description.
Chapter Preview
Top

Considering Quality Of A Service In An Intentional Approach

Service-Oriented Computing (SOC) is the computing paradigm that utilizes services as fundamental elements for developing software applications (Papazoglou et al., 2008). SOC relies on the Service-Oriented Architecture (SOA) (Alonso et al., 2004) that is a way of reorganizing a portfolio of legacy applications into services that are self-describing computational elements, which are platform independent, accessible through standard interfaces and can be assembled in complex compositions based on standard messaging protocols. Service based applications are considered as support for Business-to-Consumer (B2C) interactions and Business-to-Business (B2B) collaborations. Services, usually referred as e-services, provide well-defined functionalities that allow users and applications to meet their functional requirements (Casati & Shan, 2001).

SOC is a way of designing a software system that is function-driven and it remains at the software level. Consequently, although business people are completely familiar with the notion of service, they are totally unable to fully exploit its benefits, since they are not familiar to such software level technology. SOC technology, such as WSDL (W3C, 2007) and OWL-S (W3C, 2004) is understandable by software professionals, but far to be easily comprehensible by business practitioners. Business practitioners use to reason in terms of business goals.

The intentional Service-Oriented Architecture approach (iSOA) (Rolland et al., 2009) suggests a progress from the function-driven SOC to intention-driven SOC in order to provide a service description understandable by business practitioners. The function-driven SOC focuses on a functional view of services, whereas the intention-driven SOC spells out the purpose, the intention behind a service. The main goal of iSOA is to fill the gap between high level business services, referred to intentional service, and low level software services. The iSOA approach proposes a higher abstraction level that allows business practitioners to publish, search and compose, in terms of goals and strategies, services that can be executed in the SOA level.

On both level (SOA and iSOA), the service selection remains an important challenge, especially, when a set of services fulfills the same functionality. Among these services, one will be eventually invoked by user, generally depending on a combined QoS evaluation. The QoS can be defined as a set of non functional properties related to software service such as performance, security, accuracy and fault tolerance mechanisms (O’Sullivan et al., 2002; W3C, 2003). On the business level, Fedosseev (2003/2004) describes QoS of business process as a set of qualitative and quantitative characteristics needed to meet the initial requirements of this process. On both levels, QoS stands for non-functional properties that the service provider can ensure and that are (or can be) demanded by the service user.

The QoS plays then an important role in the software service for different reasons (O’Sullivan et al., 2002; Aiello & Giorgini, 2004): (1) a service provider may offer the same functionality with differentiated QoS (for example different prices) and must therefore publish the different qualities for this same functionality; (2) a service requester may decide for a particular service based on its QoS properties; and (3) a service may depend on other services and it needs to be aware of the QoS of the collaborating services. Therefore, QoS becomes a main concern for providers and customers of a service.

Several works in the literature (Zeng et al., 2003; Herssens et al., 2008; Aiello & Giorgini, 2004; Penserini & Mylopoulos, 2005; Ma et al., 2009) propose QoS models. Certain authors (Zeng et al., 2003; Herssens et al., 2008) consider the QoS as a collection of metrics related to non functional properties of services. Zeng et al. (2003) proposes a QoS model to describe concepts of QoS such as execution price and execution duration, whereas Herssens et al. (2008) recommend using the Unified Modeling Language (UML) to enable QoS modeling. Requirement engineering community (Aiello & Giorgini, 2004; Penserini & Mylopoulos, 2005; Ma et al., 2009) propose to reason about non functional requirements, based on the qualitative framework (Mylopoulos et al., 1992), by considering the QoS as soft goal that a service can satisficed.

Key Terms in this Chapter

Similarity Measures: Measures used to compare the degree of similarity (or dissimilarity) between two concepts on a domain.

Services: Independent entities, with well-defined interfaces, that can be invoked in a standard way, without requiring the client to have knowledge about how the service actually performs its tasks

Context-aware systems: Systems that are able to adapt their operations to the current context, aiming at increasing usability and effectiveness by taking into account environmental context

Context Models: Informational models representing context information in a well-defined structure.

Context-aware services: Services of which description is enriched with context information related to non-functional requirements, describing the service execution environment or its adaptation capabilities.

Context: Any information that can be used to characterize the situation of an entity (a person, place, or object considered as relevant to the interaction between a user and an application).

Service Selection: The process allowing the identification of all services, among the available ones, that match functional and non-functional requirements.

Complete Chapter List

Search this Book:
Reset