A Generic Model for Identifying QoS Parameters Interrelations in Cloud Services Selection Ontology during Runtime

Abstract

Nowadays, many business organizations are operating on the cloud environment in order to diminish their operating costs and to select the best service from many cloud providers. The increasing number of Cloud Services available on the market encourages the cloud consumer to be conscious in selecting the most apt Cloud Service Provider that satisfies functionality, as well as QoS parameters. Many disciplines of computer-based applications use standardized ontology to represent information in their fields that indicate the necessity of an ontology-based representation. The proposed generic model can help service consumers to identify QoS parameters interrelations in the cloud services selection ontology during run-time, and for service providers to enhance their business by interpreting the various relations. The ontology has been developed using the intended attributes of QoS from various service providers. A generic model has been developed and it is tested with the developed ontology.

1. Introduction

Cloud Computing (CC) has become a large technology caterer for infrastructure, platforms, or software as a service. The flexible and scalable pay-per-use model, virtualization of resources, and significant cost reduction makes CC a widely accepted paradigm [1]. There is an enormous number of Cloud Service Providers (CSPs) providing a variety of Cloud Services (CSs), with varied Quality of Service (QoS) attributes, available on the market. The service portrayals look like functional descriptions and treats CS attributes that are independent of one another; this conveys that accurate decisions cannot be made with this minimum descriptive information. Most of the existing Cloud Service Selection (CSS) techniques fail to interrelate and identify interdependencies among various CS attributes, and miss showcasing their close correlation by identifying how one attribute impacts another attribute, as well as the level of impact. This makes the selection of optimal CSs offered by CSPs, that suit the requirements of cloud consumers, among plenty of alternatives available on the market, a challenging task. However, as more and more CSPs are available to users, maximizing profits has become a big challenge for CSPs [2].

To impart technical descriptions of CSs provided by CSPs, a formal method that considers different QoS attributes and their interrelations is required; ontology is used to deal with this problem. Ontology provides semantic information by exploring the meanings of different attributes and identifies relationships between those attributes.

In this paper, we have identified several attributes contributing to the Infrastructure as a Service (IaaS) selection with reference to the Service Measurement Index (SMI) consortium, and have developed a QoSOnto-CSS ontology to recognize relations among the attributes and proposed a generic CSS Onto archetype. The proposed model can be used in all domains where identifying interrelations among attributes is essential; that makes this archetype a generic one that suits all service users and service providers.

The remaining sections of this paper are systematized as follows. Section 2 provides a detailed study on existing methodologies—their merits and concerns to be addressed. Section 3 details the proposed archetype for CSS, whereas Section 4 illustrates the proposed ontology. Implementation and results are discussed in Section 5. The paper is concluded in Section 6 with the scope for possible future enhancement.

2. Related Work

Ontology represents the knowledge about specific domains in a hierarchical manner, in which each level demonstrates the characteristics of a particular concept. Ontology can be used to realize interoperability, to enable interaction among software systems, and to help in human-to-human communication [3,4]. Cloud computing possess two major rulers, namely provider and consumer, imbibed in it. Cloud computing technology literature focuses on resources and services descriptions of cloud, as well as the discovery and selection of cloud services, cloud security and interoperability. Ontologies can be developed for any of these application contexts [5]. Mihaela Oprea developed an ontology for the educational domain that supports the courses, Formal Languages and Compilers, to plot knowledge representation in a much better way. This OntoFormalLanguages-Compilers-1 ontology has been taught to undergraduate computer science students at the Petroleum-Gas University of Ploiesti [6].

Mohammed et al. [7] developed a service selection ontology for PaaS users by analyzing service description documents and Web Service Description Documents (WSDD) of service providers. The developed PaaS ontology does not address QoS attributes. Zhenglan et al. [8] constructed a QoS ontology for CSS based on some of the core attributes, and involved only a small number of QoS attributes. Weights are assigned to different QoS attributes, and services are ranked using an Analytical Hierarchy Process (AHP) approach. The ontology developed by Zhenglan has no provision to dynamically update new service information in the ontology. Samer et al. [9] presented a semantic reasoner and segregated it into domain ontology and relationship ontology. Semantic similarity, along with numerical similarity, dominant similarity, and recessive similarity, is calculated to find the number of matching services for a user request. The proposed semantic reasoner does not consider QoS attributes in its service selection process.

Richard et al. [10] generated semantic rules and a logical reasoning system to collect consistent and correct feedback from users about the usage of services provided by CSPs. The ontology introduced for SaaS by the author does not involve QoS attributes. Richard et al. [11] proposed a requirements ontology that, possibly, identified the necessary user requirements utilized in service searching process, and have provided freedom in developing its own user tasks. This ontological model of Richard also did not consider QoS attributes. Yasmine et al. [12] created a SaaS domain ontology that connects various concepts through an is-a relationship. Feature similarity and request–service hierarchical similarity is computed to provide an efficient service discovery capability to the user. The author has not involved QoS attributes in the decision-making of selecting services. Ontologies have been developed to address faults that occur during the run-time of Web Services (WS) [13].

Ontologies for various applications have been in use nowadays and, henceforth, there is a requirement for generic models to find associations among attributes in ontology. Hence, a generic ontological reference, suitable for all disciplines, is proposed. With this model, a service user can find related associations among attributes pertaining to their application, and it is also useful for the service providers to update their requirements according to the specified QoS.

3. Proposed Generic CSS onto Archetype

Ontology contains a set of concepts in the domain and the relationships between these concepts. It can be applied to information retrieval to deal with user queries [14]. Ontologies and taxonomies of research topics can support a variety of applications, such as dataset integration, the exploration process in digital libraries, the production of scholarly analytics, and modelling research dynamics [15]. There are various ontologies which exist in the field of computer science, such as computer science ontology [16], gene ontology resources [17], crop ontology [18], ecology [19], eco-informatics [20], etc.

A generic ontological reference model suitable for all disciplines is a challenging issue. Hence, we propose a generic model that is used to retrieve the relationships between the various parameters in the CSS‑QoS ontology as a testing environment. The proposed architecture is as shown in Figure 1, and it would be suitable for all kinds of ontologies.

The proposed architecture consists of various components, such as service user, service provider, service repository, CSS‑QoS ontology, and the CSS Onto archetype. Service users are the ones who request the service. Service providers are the ones who provide services to the users and, the various CSPs are Amazon, Google, Microsoft, etc. CSPs provides numerous services to the users with several significant attributes, and with a fixed threshold for each of those attributes. The CSPs maintain and manage the metadata of all the services offered by them. The service repository acts as a repository of cloud services where service providers publish their cloud service. The attributes involved in cloud service selection are gathered from different CSPs and various research articles, and the ontology is developed by utilizing those attributes. The developed ontology is offered as a tool for CSPs, which need common vocabulary and semantics to communicate requirements and capabilities.

A cloud user makes a request by providing necessary attributes and the request is forwarded to the request analyzer module. The request analyzer component has been designed to delegate the validation of specified attributes. The verified attributes are given to the proposed generic CSS Onto Archetype for parsing, which results in the exploration of unknown relationships among attributes.

The steps are shown in Figure 2 and it is described below.

Step 1: Get the necessary input attribute from the user based on the relative importance of their business.

Step 2: Import the proposed ontology as an OWL file that consists of superclass–subclass relationships.

Step3: A Resource Description framework (RDF) graph is constructed from the python package mandated for RDF, called RDFLIB, and it stores the ontology diagram as a collection of RDF triples, namely subject, predicate, and object.

Step 4: Store the input attribute received from the cloud user in two fields, namely INPUT_LIST and SEMANTIC_MATCH_LIST.

Step 5: Parse the RDF Graph for identifying and formulating semantically related attributes based on the values in the INPUT_LIST.

Step 6: Find the parent of attributes in the INPUT_LIST using subclass of relation in the generated RDF Graph. If the parent is available procced for the next step else proceed for the step 9.

Step 7: Add the identified parent of INPUT_LIST to the SEMANTIC_MATCH_LIST.

Step 8: Include the identified parent to the INPUT_LIST and procced to Step 5.

Step 9: Inform the cloud user about the various service attributes they receive, in addition to the attributes stated in the service request.

Thus, the CSS Onto Archetype analyses the semantics of each attribute, and appropriate relations are identified. Cloud users are informed about the various service attributes they receive, in addition from the attributes stated in the service request.

4. QoS Parameters Ontology for Cloud Service Selection

The ontology development process of QoSOnto-CSS is detailed in Figure 1. Determining the attributes for CSS and identifying the important QoS attributes contributing to CSS, as well as verifying the significance of QoS in service selection and, based on the inference, adding those QoS attributes as classes and its sub-attributes as subclasses will be added in ontology, is shown below. Then, we have plotted the attributes as hierarchial taxonomy and interpret the relationships between attributes, if any.

To solve service selection problems, we propose a QoSOnto-CSS based on attributes specified by Service Measurement Index (SMI) consortium as reference that can be used to provide most the relevant service to the user, as per their requirements. It also provides useful information to the user about the services and their relations with other QoS parameters. The ontology is created using the protege4.2 editor, which is freely available and platform-independent. Using Web Ontology Language (OWL), it is easy to publish and share ontologies on the World Wide Web. Based on the parameters, an ontology for service selection has been developed and it is shown in Figure 3.

Functional attributes, such as Service Model, OS Series, OS Distribution, CPU Manufacturer etc., are provided by all CSPs by default. In order to make our approach different from other service selection approaches, we have considered QoS as a main class for our proposed ontology. The various subclasses that are included in QoS are illustrated in Figure 4.

4.1. Accountability

Accountability is considered to provide business reputation for CSPs due to a lack of transparency and less control over data on the market, as well as supplying good data stewardship for CSPs with compliance across geographic boundaries [21]. The accountability subset ontology is shown in Figure 5.

Accountability includes subclasses, such as impact assessments, SLA management, provider personnel requirements, sustainability, incident management, trust management, audit and certification, policy enforcement, monitoring status and violations, and data ownership. An impact assessment is a means of measuring the possible consequences that an activity may have on the privacy of an individual. SLA management is considered to be important for allocating and managing resources, as well as negation, controlling the service, reporting, and monitoring service levels with high standards. Provider personnel requirements show the extent to which CSP personnel have the skills, education, certifications, and experience required to rightly distribute a service. Sustainability has an impact on the society, the environment and the economy of the CSP by offering resources dynamically and serving multiple business users by a common infrastructure. Sustainability is common to classes such as accountability and a subclass of performance known as efficiency. Incident management has been taken into consideration for identifying any unplanned interruptions to an IT service and for recording the response actions essential for mitigating the incident.

Trust management is another vital component that helps in relational exchanges between ecommerce trading partners in a cloud environment. Audit and certification verify that the requirements follow internal policies, laws and regulations, corporate contracts, or other factors. Policy enforcement is indispensable for providing robust and flexible security and nursing for cloud-based applications and data. Monitoring status and violations parameters are incorporated, as they are important for managing and maintaining software and hardware resources, and for providing uninterrupted information for those resources and consumers deployed applications on the cloud. Data ownership details the actual proprietor of data in the CC and the landscape of data stored, as well as where it was created.

4.2. Agility

Agility is primary for any organization in order to adapt quickly to a continuously growing business environment by integrating new capabilities to address users’ growing needs, and to quickly create, test and, introduce software applications that initiates business growth [22]. Elasticity, flexibility, scalability, extensibility, malleability, and capability are the service parameters that comprise agility, and these are shown as subclasses of agility in Figure 6. Elasticity is the capacity of a system module to quickly adapt to the real-world workload demand by automatically allocating and deallocating resources. Flexibility of a CSP is based on its capability to include or eliminate predefined features from a cloud computing service (CCS). Flexibility includes two subclasses, such as portability and replaceability. Portability indicates the way a service can be shifted from one CSP to another CSP with a minimum level of distraction. Replaceability dictates the possibility of changing from one CSP to another. Scalability is characterized by increasing or decreasing the number of CCS obtainable to meet the SLAs and objectives, as agreed with clients.

Extensibility concentrates on how to include novel, real-time background support through community build packs. Malleability drives the CSP to adjust to new inclusions by clients in their previously stated requirements. Capability is significant for determining the capacity of a CSP by identifying the level of satisfaction by comparing with the standards.

4.3. Assurance

Assurance is important to avoid misinterpretations in SLAs, security or privacy policies, and standard terms and conditions, which leads to increased adoption of CSs by consumers in their business environments [23]. Assurance incorporates subclasses, such as availability, resiliency, and serviceability. Stability, fault tolerance, and reliability are the subclasses considered for availability. Service continuity, supportability, and maintainability are the subclasses included in serviceability, and these are demonstrated in Figure 7.

Availability signifies the degree to which CCS works without any failure. Stability signifies the importance of predicting interactions among independently developed but interacting CSs. The parameter of stability is common to the class usability and subclass availability of assurance. Fault tolerance is the capability of a CS to work continuously without stalling due to any unknown or unpredictable conditions or situations. Reliability is the measure of consistency provided by the CSP while delivering a service. Resiliency, as a form of failover, rectifies it by distributing redundant implementations of IT resources across physical locations. Serviceability quantifies the efficiency of the CSP in accomplishing maintenance and revising problems with the CCS. Service continuity provides the capability to deliver protection for critical applications and data that help businesses to avoid, prepare for, and recover from, a disruption. Supportability is the level of comfort provided to the users in solving their queries after delivering a CS. Maintainability is essential to ensure that adequate performance is guaranteed, with minimum maintenance costs.

4.4. Financial

Cost is one of the major factors considered by users when selecting a service, and for providers to deliver contemporary IT solutions [24]. The subclasses that characterize the financial class are on-going cost, pricing models, profit sharing, and initial cost. These are illustrated in Figure 8.

On-going cost is necessary to decide on the cost involved in managing and maintaining activities. The pricing model tends to satisfy both customers and providers by providing different packages to consumers based on their usage pattern. In the case where a CS involves multiple providers, profit sharing allows providers to split their profit based on their contribution towards the service. Initial cost involves the pricing for the data centre and the cost of installation charges, including cooling resources, real estates, electricity costs and network connection etc.

4.5. Performance

Performance indicates the ability of CS resources for carrying out jobs concurrently with extreme parallel processing, and thereby reducing the time involved, and promises more flexibility [25]. The various subclasses that have been included in performance are functionality, provisioning time, timeliness, agreement compliance, resource consumption, interoperability, accuracy, throughput, and efficiency. The subset ontology of performance is shown in Figure 9.

Functionality specifies whether the features provided by the CCS meet clients’ needs. Provisioning time refers to the time taken to provide resources to the customer or requesting application in run time. Timeliness guarantees the on-time delivery of a service to its consumers to keep them satisfied. Agreement compliance is necessary to carefully evaluate the degree to which the CSP agrees to the jurisdiction laws and policy mentioned in the SLA. Resource consumption describes the quantity of resources utilized by the CS in delivering a request to the consumer. Interoperability determines the ability of the CCS to easily interact with other services. Accuracy indicates how far the CCS adheres to its requirements. Throughput specifies the number of services successfully supplied by a CSP in a given unit of time. Efficiency measures the amount of energy consumed by the resources involved in the CS delivery.

4.6. Security and Privacy

Security in CC is a group of policies and access controls to be adhered to in order to keep data applications and information safe [26]. Privacy is the capability of an object to control the information that it acknowledges about itself to the service provider. The subclasses contributing to the security and privacy class is shown in Figure 10.

Authorization checks the correctness of data created, stored, and used, which, in turn, offers confidence to the clients that they are using accurate and valid data. Data destruction prompts the CSP to direct clients to use and share data with certain limitations. Authentication is required to validate customers who are accessing the services provided by CSP. Foreign laws are applicable if the service provider accessed by the consumer is in a different country from the user. Access controls ensures the policies and processes in use by the CSP guarantee certain privileges based on personnel and make use of or modify data or work products.

Data separation or segregation is primary in a cloud environment, as data from several users are stored in a shared environment, and one user of a CS can interfere with data of another user. Threat management security solutions are necessary to protect service provider organizations from possible attacks. Encryption necessitates the secure transmission of information. Key management tells consumers about their permissible level to read information. Logging and audits are necessary to keep track the number of clients using their service, as well as the service they are accessing. Provider access controls set by CSPs limit the user in accessing their services without proper authentication. Data location allows clients to select the location of data centers based on geographical or political factors. Physical security of data centers is to protect the infrastructure by various means of safeguarding measures that are independently audited on a need basis.

4.7. Usability

The process of achieving required goals in an effective and efficient manner is coined as usability of a system [27]. To reveal the usability of the cloud and CSs that is available to the end user, the following factors are considered, namely learnability, individualization, client personnel requirements, availability, operability, precision, installability, understandability, transparency, and interaction options. This subset of usability ontology is shown in Figure 11.

Learnability signifies the QoS and interfaces that allow consumers to quickly become familiar with the features and capabilities of that service. Individualization necessitates that service providers treat consumers as individuals and reward them with relevant offers by making them feel as if they are being remembered, being listened to and felt in control. The client personnel requirement is a crucial aspect to be considered when a service is being created and rendered to consumers for their usage. Availability indicates the amount of time a service is available for use without any failure. Operability dictates the extent to which the CCS is operable by users with disabilities. Precision initiates a detailed assessment of the client’s needs, with a focus on the business needs, the business continuity plan, and the application utilization aspects. Installability characterizes the effort, time and privilege required to get the CCS ready for deployment in a client environment. Understandability defines the level of ease for the consumer to understand a CS. Transparency demonstrates the maximum level to which users can determine the changes in a feature or component of the CCS, and the level of impression it has on usability. Interaction options show increases in conversations, create brand advocates, onboard customers, boost lifetime values, and improve customer service. Stability is important to indicate to consumers that they can access a service at any time without any problems.

5. Results and Discussion

The proposed generic model is developed using python programming language that utilizes a third-party web framework library called “flask” and a special package called “rdflib” to work exclusively with RDF.

Simple protocol and RDF query Language (SPARQL) works as a data access query interaction protocol and language that matches graphical patterns against data sources. The Web Ontology Language (OWL) file is extracted from the ontology of service selection using a Protégé editor that stores ontology relations in a Resource Description Format Schema (RDFS). The RDF data model-based query language, SPARQL 1.1, implementation has been utilized to query the semantics of each attribute and its associated relations. The ontology shown in Figure 2 is converted into an OWL file named as QoSonto.owl. This OWL file is given as input to our application that processes the hierarchies in an RDFS format and uses SPARQL to realize the relationship between attributes, if any.

The processing steps of the Generic CSS Onto Archetype are shown in Figure 12. Based on user’s interest in attributes, possible associations are mined from the OWL file extracted from the ontology.

The sample input screenshot is as shown in Figure 13, and requests the user to provide the search criteria. For the given sample requirement as assurance from the user, the subset ontology and its tracing will be identified.

When a user wishes to search for a parameter, the search criteria are sent to the request analyser. The request analyser forwards the same to the parser present in QoS Onto Archetype, which performs necessary parsing to identify subclasses of the given search criteria. After identifying the subclasses, a semantic check is performed to find suitable relationships with other classes in the ontology. As an example, when a user requests a service with attributes in assurance, the QoS Onto model identifies the common attributes present under multiple classes.

Let us consider that one of the input attributes from the user is “assurance”, and the user submits the request. The query is passed to the QoS Onto Archetype via SPARQL and a search for all the available subclasses from the RDFS is performed. The retrieved results are shown in Figure 14.

The service provider can develop an ontology for any application or any field of study using any editor, and can extract the OWL file. Our generic model accepts the OWL file of any type and identifies the relationship between attributes stated in their field of study. Thus, this generic model will be of greater advantage to anyone required to associate relations among attributes.

The proposed generic model has been tested, with fault ontology proposed by authors [13], and this generic model also suits that ontology. The RDF format of the fault ontology was extracted and given as input to the proposed generic CSS Onto archetype; it was observed that the model was able to trace the different types of errors and their correlations. Attribute selection plays a vital role in service selection and, in turn, in the development of an ontological model based on those attributes. Some authors considered fewer QoS attributes for the development of an ontology, as shown in

Table 1. QoS attributes considered by other authors.

Response Time [8,28,29,30]

Reliability [8,12,28,30,31]

Security [8,10,12,28,31,32]

Cost [8,9,10,12,28,30,31,33,34]

Usability [8,28,29,30]

Location [9,28,33,34]

Availability [9,12,28,30,31]

Adaptability [10,12,28,30]

Scalability [12,28,29,31,32]

Efficiency [28,29]

Accountability [31,32]

Integrity [1,28,32,35]

Interoperability [29,30]

Elasticity [30,36,37]

. The same is illustrated in Figure 15.

The QoSOnto-CSS ontology was constructed using 73 parameters. These 73 parameters are classified under 7 broad classes, namely accountability, agility, assurance, financial, performance, privacy and security, and usability; other attributes are plotted as subclasses for these main classes are presented in

Table 2. Major QoS attributes considered to develop the ontology.

QoS Attributes	1st Level Attributes	2nd Level Attributes	QoS Attributes	1st Level Attributes	2nd Level Attributes
Accountability	SLA management		Assurance	Availability	Stability
	Incident Management				Fault Tolerance
	Trust Management				Reliability
	Policy enforcement			Resiliency
	Impact Assessments			Serviceability	Service continuity
	Monitoring status and violations				Supportability
	Audit and certification				Maintainability
	Data Ownership		Financial	Ongoing Cost
	Provider Personnel Requirements			Pricing models
	Sustainability			Profit Sharing
Agility	Elasticity			Initial Cost
	Flexibility	Portability	Performance	Functionality
		Replaceability		Provisioning time
	Scalability			Timeliness
	Extensibility			Agreement compliance
	Malleability			Resource Consumption
	Capability			Interoperability
Security	Authorization			Accuracy
	Data destruction			Throughput
	Authentication			Efficiency	Response time
	Applicability of foreign laws				Sustainability
	End user access controls		Usability	Learnability
	Data separation			Individualization
	Threat Management			Client personnel requirements
	Encryption			Availability	Stability
	Key management				Fault Tolerance
	Logging and audit			Reliability
	Provider access controls			Operability
	Data location			Precision

. Response time is showcased for these seven main classes, but it also includes all the subclasses in it. This model is efficient when compared to other ontological models for service selection, as it considered a majority of QoS attributes.

The response time of attributes that have a semantic association is comparatively lower than those attributes that do not have associations. This observation is plotted in Figure 16.

It is observed that the response time of attributes which have interrelations is comparatively higher than those attributes which do not have interrelations. The observations from our proposed ontology, was, it has seven major QoS attributes as classes and its corresponding response time, is shown in Figure 17; it is inferred that an attribute with semantic associations takes more time to execute when compared to attributes without semantic associations.

Though the response time of attributes with interrelationships is comparatively higher than those without relationships, it is preferrable, as the semantic relationship among attributes has been found. The proposed ontology can be enhanced by considering data and object properties, axioms, and individuals for different attributes of services. Such additional inclusions to the ontology help to further refine the relationship among the provided attributes and may result in better output.

6. Conclusions

Cloud Service Selection needs to be regularized as it guarantees services requested by users. To select the service based on mandatory functional and optional QoS attributes, an ontology is developed to provide semantic reasoning among attributes of different kinds. The proposed QoSOnto-CSS ontology developed has been written in a standard ontology language called OWL, which shows its generic capability. Thus, the proposed generic QoS Onto Archetype can be used to find semantic relationships between attributes present in any ontology. It also provides an abstract perspective with which it is possible to infer knowledge, follow common objectives, and interoperate for service providers and service users. The proposed model has been tested using an application with sample inputs and necessary interrelations derived as output shown. For the future work, we plan to extend the generic model to have more possible associations among the various attributes.