3.5
Multi-Objective Service Selection Optimization
Service selection problems, as many other optimization problems, can have more than one objective function. Objectives are usually competing, i.e., the best solution with regards to one objective can be the worst with regards to another objective. A good solution is thus a compromise between the various objectives. For example, in a service selection scenario one might want to minimize the expected execution duration while also minimizing costs. Assuming that better performing services cost more than less performing ones, a decrease in execution time will result in an increase of the related costs. These problems are referred to as Multi-Objective Optimization Problems (MOOP) and are discussed in Chapter 5 (Section 5.4). In the following, recurring competing objectives and approaches to solve MOOP in service selection scenarios are briefly outlined.
Several authors formulated specific service selection challenges as multi-objective optimization problems [62, 72, 90]. Liu et al. [62] describe a scenario with two objectives, namely minimizing the execution time and minimizing the costs, and impose constraints on reliability and reputation. The authors propose a strategy for global optimization of dynamic Web service selection based on a multi- objective genetic algorithm. Qiqing et al. [72] aim at finding a concrete workflow that minimizes cost and time, and maximizes the overall reliability while meeting user-defined QoS constraints. To address this multi-objective optimization problem, they propose a Multi-Objective Ant Colony Optimization (MOCACO) algorithm. The authors compare their algorithm to a multi-objective genetic algorithm proposed in [62] and show that, for different test settings, MOCACO outperforms the GA both in runtime performance and in the solution quality. An evolutionary approach is also presented in [90], where minimizing costs and maximizing throughput are the two competing objectives.
Yu and Bouguettaya [103] propose using multi-objective optimization techniques to compute
service skylines. A service skyline is a small set containing the best services regarding defined
criteria. The aim is to return to the user a set of services that satisfy his requirements and represent good (non-dominated, cf. Chapter 5, Section 5.4) solutions to multiple objective functions. This way, the user can himself choose a service, but is not confronted with the whole set of available ones. The concept of a service skyline is inspired from the concept of top-k queries in database systems.
Related work on multi-objective service selection optimization using EA is studied in more detail in Chapter 6 (Section 6.5).
Chapter 4
An Ontology of Components and
Attributes of Distributed,
Service-Oriented Systems
Many modern computing systems, be they for scientific or business applications, are designed as service-oriented systems, i.e., self-contained pieces of functionality are provided in individual services that can act independently or together. Additionally, for performance, scalability, and reliability reasons, they can be distributed across geographical sites and even organizational boundaries. In- deed, components of a service-oriented model can be easily distributed due to their self-containment. However, such a system also requires a high level of management, in particular if the distributed units are heterogeneous, i.e., not necessarily pure standard-conform Web services that are described in a SOAP interface and can be discovered via UDDI. Therefore, it is important to have a mech- anism to describe and monitor such systems. To this end, this chapter presents a system and attribute ontology and classification. Its purpose is to identify the building blocks of heterogeneous, service-oriented systems and the attributes characterizing those blocks. The proposed models are customized to the TAG system, showing their applicability to a real-world example. Finally, a con- crete implementation of a service registry – the so-called TAG Application Service Knowledge Base (TASK) – is described.
This chapter is organized into sections as follows. In Section 4.1 the purpose and scope of on- tologies are outlined, and the methodology adopted in this chapter is described. Section 4.2 presents the generic system ontology and its application to the TAG system, defining the individual system components and their interactions. In Section 4.3 system attributes, specifically QoS attributes, are studied in detail. A QoS attribute taxonomy is presented and applied to the TAG system, and attribute aggregation functions are defined. Section 4.4 details design and implementation consid- erations of TASK. Finally, Section 4.5 summarizes the key notions and concludes this chapter.
4.1
Methodology
Many different parties are usually involved in the design, implementation, operation and support of a large-scale, distributed system. In the TAG use case for example, system engineers and de- velopers are members of the ATLAS collaboration, working in different countries, time zones, and institutions, although all belonging to the same Virtual Organization (VO), namely ATLAS. The collaborative aspect and efficient communication structures thus play an important role. Addition- ally, all contributed pieces of software have to work together. This is referred to as an interoperability requirement. It is thus crucial that all involved parties have a common understanding of the system and its scope and building blocks as well as their interactions. Therefore, it is beneficial to build and agree on a system model and related vocabulary. This eases communication and future software contributions as well as the adoption of optimization strategies on the existing system.
Ontologies are a means to achieve the above stated goals. An ontology is a shared understanding of a domain of interest, generally viewing this domain as a set of concepts, their definitions, and their inter-relationships [81]. It defines a structured namespace built upon hierarchies that sets the semantics of the system it has been designed for. Its primary benefit is to define a common vocabulary that has to be used by all those interacting with the system. The benefits of defining and using ontologies in the area of service-oriented systems and service selection have been pointed out by Yu and Bouguettaya [103] in their work on foundations for an efficient selection of Web services. The authors characterize an ontology as shared (i.e., the involved parties have to agree on it), explicit (i.e., all terms are explicitly defined) and formal (i.e., described in a well-defined and unambiguous model or specification language). The definition and representation of an ontology range from a simple classification to a fully axiomatized theory, each providing a different level of formality. Uschold and Gruninger [81] propose four degrees of formality an ontology can provide:
1. highly informal : expressed loosely in natural language.
2. semi-informal : expressed in a restricted and structured form of natural language. 3. semi-formal : expressed in an artificially defined language.
4. rigorously formal : precisely defined terms with formal semantics, theorems and proofs of, for example, soundness and completeness.
Ontologies are used in several different communities, and they are a central part in many kinds of applications, such as knowledge portals, information management systems, and semantic Web services [77].
As pointed out in [81], there are three main areas that can benefit from an ontology: communi- cation, interoperability and systems engineering, as depicted in Figure 4.1. Those three areas are of central interest in distributed, service-oriented systems. First, it is all about engineering a system composed of services acting as autonomous, high-level building blocks. Second, those services are required to operate together, often across organizational boundaries. Third, the involved organiza- tions and their people need to communicate in order to develop and deploy inter-operable services. Ultimately, the goal is to compose those services together in order to fulfill a complex workflow. As shown in Chapter 2, this is in particular a requirement of the TAG system.
4.1. METHODOLOGY 51
Ontology
Communication (people, organizations) Inter- Operability (systems) Systems Engineering (reusability, reliability, specification) facilitatesFigure 4.1: Areas for Ontology Uses
In [81], the authors also provide a general methodology for developing an ontology. The required steps are depicted in Figure 4.2. First of all, the purpose and scope, i.e., the domain the ontology is aimed at, have to be defined, including a definition of the organization and users supposed to adopt it. The second step is the building of the ontology itself. All the key concepts of the defined domain and their inter-relationships have to be identified, precisely (and unambiguously) defined, and a naming convention has to be adopted. These sub-steps are referred to as capture. They are followed by the coding of the ontology in the chosen representation language. If other ontologies already exist for a similar domain, those can either be integrated, or the reasons for building a completely new one should be explained. Design considerations include clarity, coherence, extensibility, minimal ontological commitment (include just enough details to enable a common understanding of the domain of interest, but do not overload) and minimal encoding bias (minimize particular encoding).
The third step is the evaluation of the ontology. The formal evaluation consists of applying a
reasoner to the ontology, to check for inconsistencies in the semantic definitions of the represented concepts. The more practical evaluation though, i.e., the applicability and usefulness of an ontology for its specified domain, can best be assessed by using it for the sort of application it has been intended for. This is done in this work by deriving an optimization problem based on the concepts defined in the ontology. Finally, good practice and efficient reusability dictate that the ontology should be annotated and documented. It is of particular interest to document special design choices. These steps have been followed in the building of the ontology described in the next sections. The evaluation has been carried out on the TAG use case scenario.
In the subsequent sections, a system and an attribute ontology are proposed and applied to the TAG use case. The aim is to provide a template for describing the building blocks of a distributed, service-oriented system, and relevant attributes in general. By applying these models to the TAG system, the foundations are laid to allow the definition of a concrete service selection optimization problem.
Define the purpose and scope of the ontology
Build the ontology: Capture
Coding Integration
Evaluate the ontology
Document the ontology
Figure 4.2: Methodology Applied for Building the Ontologies