Cloud Services discovery and Composition represents a hot topic, due to the high number of Cloud Ofers currently available, and the extreme variability in the exposed services' interfaces. Such a variability often results in interoperability and portability issues of applications and data among diferent Cloud Platforms, especially considering that Providers themselves often tend to lock-in their own users. Semantic technologies have indeed shown the capability to reduce such issues for users, by providing a common and shareable set of concepts, properties and relations that can be used as a ground to eficiently compare Services and adapt their exposed interfaces. In this work, a semantic description of Cloud Services and their agnostic composition is used to support users in implementing their own solution, by explicitly declaring their requirements. The proposed Expert System uses an existing semantic representation of Cloud Services, which has been further extended, and OWL-S descriptions of Agnostic Services compositions, which are then mapped to a set of Vendor Specific Cloud Services, to discover the required Services and finally compose a solution for the user. Users' requirements are analysed and processed by logical rules written in Prolog, which take care of building the actual composition. In this paper such and Expert System is described in terms of its main inputs and outputs, together with a description of the extended knowledge base used to represent the Cloud Services, and of the OWL-S definitions of Agnostic Services compositions. Also, the Prolog rules used to create the Provider specific ∗Corresponding author. †These authors contributed equally.
Cloud Services compositions are reported.
Cloud Computing has been widely adopted, during past years, by several companies and enterprises, especially of small and medium dimension. The high availability and reliability of Cloud Services have strongly influenced and incentivised the adoption of Cloud solutions, also considering the virtually infinite amount of resources that Cloud Platforms can provide. This is strengthened by the relatively reduced necessity of initial investments that using Cloud solutions implies. One of the main drawbacks that several companies need to address, when approaching the Cloud Market, is represented by the extreme variety of available solutions, which is paired by a general lack of formal, homogeneous descriptions of ofered services. This fact hinders the adoption of Cloud solutions, as the potentially of existing services in often hidden by their lack of description or overshadowed by the technical dificulties which arise when trying to build a complex solution, possibly merging several existing services. Indeed, interoperability and portability issues are quite common when users try to create a complex service starting from existing Cloud ofers, especially when the composing services are exposed by diferent companies and Cloud platforms.
This is where the adoption of Semantic Technologies for the description of Cloud Services, their composition and orchestration, has demonstrated to be a possible solution to the lack of formal descriptions of Services interfaces, dramatically mitigating interoperability and portability issues.
Indeed, a Semantic representation of Services can be seamlessly exploited to achieve two diferent goals.
The first one consists in defining a simplified means for users to access descriptions of Services interfaces. This can be done by querying a Semantic knowledge base that, on the base of specific requirements expressed by the users themselves, proposes a set of available Cloud Services suiting such requirements.
The second one is instead focused on identifying possible compositions of identified Services which, once adequately orchestrated and eventually adapted, provide complex functionalities as requested by the user.
The two aforementioned goals can be treated separately, considering the Services Discovery as a preliminary, necessary step to Services Composition and Orchestration. Indeed, in this paper the two diferent aspects are treated separately, with a focus on the discovery goal. By leveraging a Semantic Description of Agnostic Cloud Services, obtained through an OWL Ontology which will be briefly introduced in Section 2, representing generic exposed functionalities that can be then composed together, the prototype tool proposed in this paper selects the actual Vendor Specific Services and propose a collection thereof, meeting the requirements expressed by the user. Logical rules expressed in Prolog allow for the identification of the required Services. Furthermore, to enable the actual composition and orchestration, OWL-S is exploited: in this way the expert system prepares the ground for actual orchestration, by leveraging a composition of Services using the OWL-S formalism.
The remainder of this paper is organised as follows: Section 2 provides an introduction to the CSOntology and to OWL-S, which are necessary to understand the presented work; Section 3 describes the main components of the proposed Expert System; Section 3.1 provides an insight on the main extensions provided to the existing CSOntology; Section 3.2 focuses on the semantic representation of Agnostic Services, which is needed by the Expert System to define higher level Service Compositions; Section 3.3 describes the NFR class used to represent Non-Functional Requirements; Section 4 provides a description of the Prolog rules used by the Expert System; Section 5 closes the paper with some final considerations and remarks.
Classification, categorisation, discovery and Composition of Cloud Services has to be considered
as a hot topic, considering the consistent number of research eforts on its regards [
In this Section an Expert system supporting users in the Composition of Cloud Services is
presented. The main objective of the System is to identify a possible composition of Provider
Specific Cloud Services, starting from a high-level description of a composition built upon
Agnostic Services, acting as a guide for the selection of actual Services. Such Agnostic Services are
automatically selected by the Expert System by applying a set of Non Functional Requirements
(NFRs) expressed by the user.
The general design of the Expert System is reported in Figure 1. In order to work, the framework
requires three diferent kinds of inputs, allowing it to apply logical rules and create the Service
Composition:
• A knowledge base represented by an Ontology of Cloud Services, comprehending
Comprehending TBox and ABox statements that can be used by the Expert System to identify the
best suiting Services and implement their composition. This role will be covered by and
extension of the CSOntology, which will be called CSOntologyExtended from here on,
and that will be discussed in Section 3.1. In order to apply logical rules to such a semantic
knowledge base, the software Thea [
The output of the System is instead represented by the exact composition of Cloud Provider Services to use to obtain the high-level functionalities required by the user, explicating the sequence of calls among the composing Services which is necessary to build the overall workflow of the composition.
As already stated in Section 3, the Knowledge Base represented by the CSOntologyExtended
has been built upon the CSOntology briefly introduced in Section 2 and described in detail in
[
(b) Overview of the CSOntologyExtended extension. In order to create the CSOntologyExtended, new Providers, Service Categories and Service Instances have been taken in consideration. In particular, the dataset provided by the Public Project Cloud Comparer1 has been used a source to extend the Cloud Categorization and introduce new Services and relative parameters.
Cloud Comparer aims at describing a series of Cloud and Web Services, divided into Providers and Categories, so that similar Services ofered by diferent Providers can be compared. The dataset can be downloaded as a JSON file, structured as shown in Listing 1.
Listing 1: Excerpt of the JSON dataset provided by Cloud Comparer "category": {"name": "Compute", "ref": ""}, "service": {"name": "Virtual Server", "ref": "", "Properties": [ "Number of instance templates available", "GPU acceleration", "Custom instance creation feature", "CPU Limits", "Memory Limits", "Temporary Storage Limits" ]}, "aws": [{"name": "Amazon EC2", "ref": "https://aws.amazon.com/ec2/", "icon": "Compute_AmazonEC2.png", "Properties": ["39", "Yes","No","1 - 40","0,5 - 244 GB", "Up to 48 TB (
Multiple Disks)"} }]
This part of the dataset shows the Services belonging to the Compute category, of type BareMetal, and compares diferent alternatives. As an instance, Amazon Web Services (AWS) ofers the Amazon EC2 Bare Metal Instance, which has some specific declared characteristics that can be compared with other ofers from diferent providers.
The information derived from the Cloud Compare project have been used to extend and populate the CSOntology. In particular, Pyhton scripts exploiting the owlready22 library have been created.
In order to correctly populate the ontology, new classes have been defined as subclass of the ServiceCategory class. The new classes comprehend categories listed in the Cloud Compare dataset, such as Compute,Mobile Services, Artificial Intelligence . Individuals have been created considering the actual Services described by the dataset, such as the Azure Bare Metal Serve described in listing 2.
Listing 2: Excerpt of the JSON dataset provided by Cloud Compare defining a Service "azure": [{ "name": "Azure Bare Metal Servers (Large Instance Only for SAP Hana)", "ref": "https://docs.microsoft.com/en-us/azure/virtual-machines/workloads/sap /hana-overview-architecture", "icon": "Azure Virtual Machine.png", "Properties": [ "39", "Yes", "No", "1 - 40", "0,5 - 244 GB", "Up to 48 TB (Multiple Disks)" ]}] New instances have been used to populate the ontology, such as Shared Web Hosting, Virtual Server, Auto Scaling and Batch Jobs, considered as instances of Compute.
A Service description, as provided by Cloud Comparer, contains several properties. These have been translated into DatatypeProperties, having the specific category class as a domain. Indeed, each category has its own properties, which have been dynamically created by analysing the JSON. Figure 3 shows class AutomatedDisasterRecoveryServices, its specific properties and instances. AutomatedDisasterRecoveryServices is a subclass of DisasterRecovery, and it is the domain of the Ref (url of a reference website) and oferedBy (connecting the Service to its Cloud Provider) properties, and comprehends several instances, among which azureBackup and azureSiteRecovery. Among other instances, it is also possible to identify Agnostic_ AutomatedDisasterRecoveryServices. Such an individual describes an agnostic Service that represents the entire class: ServiceCategory’s subclasses all have one of such agnostic Service individuals, which are used to create agnostic compositions with OWL-S.
The CSOntologyExtended ontology contains a CloudService class, with two subclasses, AgnosticCloudService and VendorSpecificCloduService . AgnosticCloudService is the type to which all agnostic Services refer, while vendor specific Services are instances of VendorSpecificCloduService.
So, each individual is considered as an instance of two separate classes: one is a subclass of ServiceCategory, the other can be either AgnosticCloudService or VendorSpecificCloduService. An individual of the AgnosticCloudService class is considered as the domain of the isServiceEquivalent ObjectProperty, whose range is instead represented by VendorSpecificCloduService. This property expresses equivalence among Services, and is used to identify vendor specific Services corresponding to agnostic Services. An example is show in Figure 4, where the prop2https://pypi.org/project/Owlready2/ erty has been instantiated for the individual Agnostic_ApplicationService. Such individual belongs to two diferent classes, AgnosticCloudService and ApplicationServices: the former identifies Agnostic_ApplicationService as an agnostic Service, while the latter declares it to be an Application Service. The equivalent individuals can either be Vendor Specific Services (such as IbmCloudFunctions in the example) or Agnostic Services (such as logicApps in Figure 4).
The second input of the Expert System is represented by the description of Agnostic Services, which is used to allow it to identify an optimal configuration, or more than one, of Vendor Specific Cloud Services, starting from an initial agnostic composition. OWL-S is exploited to represent such agnostic Service compositions.
In order to describe how OWL-S is exploited in this approach, we are going to describe an agnostic composition which is named watchFilm. This agnostic composition allows to watch iflms after logging in to a Remote platform, which analyses the user’s behaviour though a Big Data service to enhance her experience. So, the watchFilm Service is composed of a Login service, and a SelectedForYou Service, which proposes a catalogue of films to watch, according to the past selections made by the user. SelectedForYou is in turn composed of simpler agnostic Services, BigData&AI, scalableDatabase and agnostic_Compute. These Services could be further broken down, but for simplicity we will stop at this level. Figure 5 shows such a composition: each ellipse represents a Service, and the arrows describe a ”composed of” relationships. Let’s suppose a User requested the watchFilm Service. This would in turn rely on the Login Service to identify the User, in order to retrieve her personal information. Such information would be used by the selectedForYouService to retrieve a list of suggested films, which in turns relies on scalableDatabase as a data source for films, BigData&AI to analyse the User’s preferences, and agnostic_Compute to run the actual calculation.
This specific composition is obtained through OWL-S, using the Services defined in the CSOntologyExtended as a reference. In order to define the composition, the SERVICE class deifned by OWL-S is populated with individuals representing the agnostic Services constituting it, as shown in Figure 6. Each of the shown individuals is connected to an instance of the COMPOSITEPROCESS class defined by OWL-S through the ObjectProperty describedBy (also defined in OWL-S). Viceversa, each COMPOSITEPROCESS is connected to a SERVICE individual through the describes ObjectProperty. In our specific case, selectedForYou_COMPOSITEPROCESS is a composed process that describes the selectedForYou_SERVICE. The selectedForYou_COMPOSITEPROCESS is in turn constituted by the Services listed in Figure 6, through the hasParticipant ObjectProperty, as shown in Figure 7.
All the Services used as participants in this composition are being defined in OWL-S as a further composition of simpler Services, but the ones that cannot be broken down are directly connected to an agnostic Service from the CSOntologyExtended ontology. This is the case for the Agnostic_IdentityAccessManagement Service, which is used as a participant ah the watchfilm_COMPOSITEPROCESS directly.
In order to describe Non-Functional Requirements (NFR), a new class has been defined in the ontology, which has been then populated with individuals representing several kinds of requirements, such as scalability (nfrScalability), security (nfrSecurity), use of a specific kind of Database (nfrRelationalDB for a Relational Database) and so on.
In order to connect a Service Category with a specific NFR, the hasTargetService has been created, and it has been explicitly exploited for the definition of the NFR class itself. As it is shown in Figure 8, a series of connections have been created between the nfrScalability individual and the Services satisfying Scalability requirements. If we take in consideration the Scalability requirement, which is satisfied when the architecture of a system is dynamic and additional servers can be added as needed, then a first rule that can be implemented in the knowledge base states that a Service composition will be scalable if all of its constituting Services (either simple or composite) are also scalable. The logical rules that the expert system will use in order to create the Services Compositions will take in consideration such definitions, which will in turn be represented by ad-hoc Prolog rules.
Once the semantic description of the Services composition is ready, it is directly transformed into a series of Prolog fact through the Thea software.
A set of low level rules have been defined, which represent the baseline to describe higher level relationships and complex inferences. These low level rules are divided into three categories: • Rules to identify the Class to which a Service belongs. • Rules to check if a Service belongs to a specific Vendor and it is this recognisable as a
Vendor Specific Service.
• Rules to identify Agnostic Services.
The OWL-S structure is then transformed into a Prolog Functor, by using a recursive rule that navigates composite processes until it reaches an Atomic or Simple Process, as defined by the OWL-S standard.
In the example described in Section 3.2, watchFilm was a COMPOSITEPROCESS, constituted by the Login and selectedForYou Services, the latter being again composite. The recursive rule generating the resulting functor is provided in Listing 3.
functorAgnosticCompositeService(S,Res,F):- classAssertion(agnosticCloudService,S), add(S, [],Res), F =..[S]. functorAgnosticCompositeService(S,Res,F):-compositeProcess(S),findall(P, serviceParticipants(S,P),Part), functorAgnosticCompositeService(Part,Res,_),flatten( Res,FRes),F =..[S|FRes]. functorAgnosticCompositeService([Sh],Res,F):-functorAgnosticCompositeService(Sh,_,F),Res = [F]. functorAgnosticCompositeService([Sh|St],Res,F):-functorAgnosticCompositeService(Sh,_,F1), functorAgnosticCompositeService(St,_,F2), Res = [F1,F2],F = [F1,F2].
The rule analyses each Service and its components by using the findall call, and it recursively explores all the new identified Composite Process. The recursion stops when the exploration does not provide new Composite Processes to further analyse.
Once a Service composition is retrieved, it is necessary to verify if it satisfies the NFRs expressed by the user.
First, all the Services of the composition are analysed to check the agnostic requirements introduced in the ontology as described in Section 3.3. The Prolog rule used for this in shown in Listing 4. The rule analyses a Service S and a Requisite R, to verify if it is satisfied through the hasTargetService property. Using Prolog predicates such as setof it would be possible to have a complete list of satisfied requirements.
agnosticMatch(S,R):- functorAgnosticCompositeService(S,_,F), subterm(T,F), propertyAssertion(hasTargetService,R,T).
Once the agnostic composition has been checked and it satisfies the user’s requirement, it is possible to choose matching Vendor Specific Services, by specifying further requirements on the characteristics of the Service. This is done by examining the DataProperties associated to the Vendor Specific Services, which have been defined in the Service ontology, as described in Section 3.2. Such properties are directly transformed by Thea in Prolog facts, which can be immediately used in logical rules.
Let’s consider again the composition obtained for the watchFilm Service. In order to request the Vendor Specific Services that satisfy the user requirements, as an instance on the BigData&AI and ScalableDatabase Services, the rules shown in Listing 5 have been applied.
Listing 5: Prolog Rules to check constraints on BigData&AI and ScalableDatabase Services matchBigDataConstraint(S,Functor):agnosticToVendor(agnostic_BigDataQueryAsAService,R1), propertyAssertion(memoryLimits_GB,R1,Exp1), intValue(Exp1,Val),Val>300, functorCompositeService(agnostic_BigDataQueryAsAService,R1,F1), agnosticToVendor(agnostic_MachineLearning,R2), propertyAssertion(gpuAcceleration,R2,Exp2), boolValue(Exp2,true), functorCompositeService(agnostic_MachineLearning,R2,F2) -> functorCompositeService(bigDataAI_COMPOSITEPROCESS,[F1,F2],Functor),
S = bigDataAI_COMPOSITEPROCESS.
The BigData&AI service is required to have at least 300GB of available RAM, and a dedicated GPU for Machine Learning. Through the agnosticToVendor rule, the Prolog engine can identify Vendor Specific Services corresponding to an Agnostic one, provided that they satisfy a set of specified requirements. In the example reported in Listing 5, agnosticToVendor is first used on the agnostic_BigDataQueryAsAService Service, which is an agnostic Service providing Big Data functionalities, to identify Vendor Specific Services that satisfy the 300 GB minimum memory requirement. Then, the same rule is applied to the agnostic_MachineLearning individual, identifying generic Machine Learning Services, by finding Vendor Specific Services that ofer Machine Learning functionalities that, at the same time, have GPU support. The identified services are composed together by the final functorCompositeService funtor.
In this paper, an Expert System has been presented with the capability of providing users a composition of Vendor Specific Cloud Services, starting from an agnostic definition of such a composition and a set of logical rules, used to identify Services which satisfy specific non Functional Requirements. The agnostic composition is described by combining an ontology of Cloud Services, which has been obtained by extending the already existing CSOntology with information extracted from the Cloud Compare dataset, and the structure provided by OWL-S. Several classes and new individuals have been added to the original CSOntology, here renamed as CSOntologyExtended, by using the information available on the Cloud Comparer website, which provides an in depth comparison among Cloud Services from several Vendors. In particular, the JSON representation of the Cloud Services exposed by Cloud Comparer have been automatically extracted and used to populate the new CSOntologyExtended. The frameworks leverages the Thea software to translate the Ontological knowledge base into a Prolog set of facts and assertions, which represent the base of executable logical rules. The logical rules which have been defined allow for the creation of Prolog functors, that express the composition of Services, which are specifically selected in order to provide the exact requirements requested by the user. The resulting Service compositions can satisfy multiple requirements at the same time. At the moment, the logical rule that express the NFRs chosen by the user are still quite limited and hard coded, as they are not generated automatically, but they require to be expressed either as new Prolog rules, or as SWRL rules that can be evaluated by an inferential engine. However, in the future we will study a means to dynamically create such rule, according to the User’s actual requirements, by means of a graphical interface that can help her to express such requirements. Also a real system design as a service, useful also to evaluate the scalability and the usability of the tool, will be realised.