Considering Quality of a Service in an Intentional Approach

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.