Article Preview
Top1. Introduction
Service-oriented structures allow web developers to organize individual programs into a set of interconnected services, accessible interfaces and standard protocols (Lopez-Velasco, 2008). These structures enhance flexibility in the maintenance and development of systems, and ensure a high degree of interoperability between heterogeneous systems. The most used technology to migrate to this architecture is the Web service, a computer program for communication and data exchange between applications and heterogeneous systems in distributed environments (Newcomer, 2002).
Generally, Web services are only described on the functional level. In fact, SOAP is a protocol for only transporting XML messages between Web services. The Universal Description Discovery and Integration (Newcomer, 2002) (UDDI) is a homogeneous description model of Web service directories. The Web Services Description Language (Newcomer, 2002) (WSDL) is a standard description that remains purely syntactic; i.e., it addresses the way in which the service is used and not what the service does. Finally, WS-BPEL is the standard for business process modeling and Web service orchestration that focuses on functionality. The problem with these description and modeling languages is that they are semantically poor and conceptually far from the concerns of the users. In order to enhance this service description by semantic information, many languages, such as OWL-S (Burstein et al., 2004), WSMO (De Bruijn et al., 2006), AWSDL (Akkiraju et al., 2005), to name a few, have been proposed. The addition of semantics aims at supporting automatic interoperability for heterogeneous systems.
However, even when semantically enriched, the service description is always discrepant from the concerns of the users, specially who are technologically illiterate. In fact, most users have difficulties in understanding and express their requirement in terms of input, output, precondition, etc. They need to express their requests in their own words and with their own language, to describe an intention and reveal a goal that they wish to achieve through a service without being aware of how to perform it (Najar et al., 2011). The question that arises here is how to correspond between the user’s intention and the functionality of the software services.
In order to solve this problem, several studies have tried to identify the intentions of the users and find the services which can perform them. Some researchers introduced the intentional oriented architecture (ISOA) which aligns the user’s needs in the form of goals (Driss et al., 2011; da Silva Santos et al., 2009). Goal defines what the user wants to accomplish through the service. Nevertheless, these studies have integrated the concept of goal only from the side of the users. Information about the users’ intention is seldom congruent with the software service description (Najar et al., 2011). The absence of goal/intention in a service description reinforces the “mismatch” existing between the functionality of the service described in low-level technical statement and the user’s intention that represents a high-level description.
In our previous work (Khanfir et al., 2015), we proposed a service description that integrates the concept of intention. With the appearance of new technologies in the user’s dynamic environment, however, new challenges emerged. Such challenges include not only discovering services that meet the users’ intentions, but also taking into account their contexts and Quality of Service (QoS) performance. The context is seen as “…any information that can be used to characterize the situation of an entity. An entity is a person, place, or object that is considered relevant to the interaction between a user and an application, including the user and applications themselves.” (Dey, Abowd, & Salber, 2001). The QoS plays a significant role in the software service (Ait-Ali-Slimane et al., 2011). A service provider may offer the same functionality with different QoS (for example different prices). In fact, to satisfy the user’s intention, the relevant services should not only fulfill the goal. They also must adapt its execution to the user’s context and guarantee a high QoS.