Virtual Cloud Bank: Cloud Service Broker for
Intermediating Services Based on Semantic Analysis
Models
Joonseok Park Research Institute of Logistics
Innovation and Networking Pusan National University
Busan, Korea [email protected]
Youngmin An Department of Electrical and
Computer Engineering Pusan National University
Busan, Korea [email protected]
Keunhyuk Yeom*corresponding author Department of Electrical and
Computer Engineering Pusan National University
Busan, Korea [email protected]
Abstract— With the expansion of the cloud computing paradigm, various cloud services are emerging. As a consequence, the utilization of cloud services has increased. However, the complexity of cloud service usage is also increasing, because the cloud providers have different performance levels and prices for cloud services that offer similar functions. Therefore, there is a need for a Cloud Service Brokerage (CSB). CSBs act as intermediaries to the cloud services to fulfill the requirements of the tenants. In this paper, we present a CSB called a Virtual Cloud Bank (VCB). This includes a Tenant Analysis Model, which is used to collect and analyze the tenant requirements, a Service Analysis Model, which is used for the specification and analysis of various cloud services, and a Cloud-service Query and Inference Model, which is used for querying and inference of the cloud services. Our VCB can be utilized as a reference architecture for providing tenant-centric cloud services.
Keywords—cloud computing; cloud service brokerage; cloud service inference; service brokerage architecture; cloud service query
I. INTRODUCTION
The cloud computing paradigm [1][2][3] is an on-demand Information Technology (IT) environment. It denotes a computing environment that provides IT resources (e.g., software, platform, and data storage) for services using an Internet connection at any time and from any location. With the advent of this paradigm, a large number of IT companies, e.g., Amazon, Google, and Microsoft, now provide XaaS-type cloud services, including Amazon EC2, Google App Engine, and Microsoft Azure.
According to Gartner [4], through the activation of cloud services, growth in the cloud solution market will reach US$3,689 million in 2017. As more and more cloud services are activated, the need for individuals and business to use cloud services is increasing. However, the current provisioning of cloud services is provider-dependent. This means that the cloud tenants themselves must contact their cloud service providers, such as Amazon and Microsoft, directly. A cloud tenant is a user of a cloud service who must find sufficient services that fit their needs. We separate tenants into three types: single users, corporations, and communities.
The number of cloud service providers that offer similar cloud services is increasing. However, this has resulted in complexity and difficulty in selecting cloud services, because providers have different performance levels and prices. Tenants should thus compare and analyze the cloud services in which they are interested.
With the fast growth in the number of cloud services, and to solve the aforementioned difficulties, the need for a Cloud Service Brokerage (CSB) has been presented. CSBs act as intermediaries between tenants and cloud service providers. Gartner and NIST [5] first suggested the concept of a CSB [6][7][8][9]. Since their introduction, according to Gartner, the number of CSB companies increased from 12 to several hundred between 2011 and 2012. In addition, the market size for CSBs is forecast to increase by 18% from 2012 to 2017.
Current CSB companies such as Accenture and Infosys locate cloud domain experts in their role as an intermediary. Cloud domain experts manually analyze the tenants by focusing on companies’ requirements. Using such analysis, the role of a CSB is to consult and install cloud services that fit these companies’ requirements. Companies spend a great deal of time using cloud services, because the required analysis is conducted manually by cloud domain experts. The targets of CSBs are companies, and not individuals. In these CSB structures, individuals are unable to use cloud services.
In this paper, we suggest the use of a CSB called a Virtual Cloud Bank (VCB). The objective of this VCB is the automatic provisioning of tenant-centric cloud services. The key contributions of our research can be summarized as follows:
• a tenant analysis model to collect and analyze tenant requirements;
• a service analysis model to specify and register various types of cloud services;
• the intermediation of cloud services that match tenant requirements;
• the automatic provisioning of cloud services without the need for cloud domain experts;
• the conceptualization of a VCB architecture.
Cloud providers specify and register their cloud services to our VCB based on the proposed Service Analysis Model “This work was supported by the National Research
Foundation of Korea(NRF) grant funded by the Korea government(MSIP) (No. NRF-2013R1A2A2A01068256).”
UIC-ATC-ScalCom-CBDCom-IoP 2015 978-1-4673-7211-4/15 $31.00 © 2015 IEEE DOI 10.1109/UIC-ATC-ScalCom-CBDCom-IoP.2015.191 1022 UIC-ATC-ScalCom-CBDCom-IoP 2015 978-1-4673-7211-4/15 $31.00 © 2015 IEEE DOI 10.1109/UIC-ATC-ScalCom-CBDCom-IoP.2015.191 1022 UIC-ATC-ScalCom-CBDCom-IoP 2015 978-1-4673-7211-4/15 $31.00 © 2015 IEEE DOI 10.1109/UIC-ATC-ScalCom-CBDCom-IoP.2015.191 1022 UIC-ATC-ScalCom-CBDCom-IoP 2015 978-1-4673-7211-4/15 $31.00 © 2015 IEEE DOI 10.1109/UIC-ATC-ScalCom-CBDCom-IoP.2015.191 1022 UIC-ATC-ScalCom-CBDCom-IoP 2015 978-1-4673-7211-4/15 $31.00 © 2015 IEEE DOI 10.1109/UIC-ATC-ScalCom-CBDCom-IoP.2015.191 1022 UIC-ATC-ScalCom-CBDCom-IoP 2015 978-1-4673-7211-4/15 $31.00 © 2015 IEEE DOI 10.1109/UIC-ATC-ScalCom-CBDCom-IoP.2015.191 1022 UIC-ATC-ScalCom-CBDCom-IoP 2015 978-1-4673-7211-4/15 $31.00 © 2015 IEEE DOI 10.1109/UIC-ATC-ScalCom-CBDCom-IoP.2015.191 1022 UIC-ATC-ScalCom-CBDCom-IoP 2015 978-1-4673-7211-4/15 $31.00 © 2015 IEEE DOI 10.1109/UIC-ATC-ScalCom-CBDCom-IoP.2015.191 1022
(SAM). The VCB can collect and analyze the tenant requirements using a Tenant Analysis Model (TAM). In addition, the VCB can query and infer suitable cloud services using a Cloud-service Query and Inference Model (CQIM). Based on this semantic analysis model, the VCB can conduct the seamless tenant-centric provisioning of cloud services.
The remainder of this paper is organized as follows. Section II discusses previous research related to this topic. Section III presents the semantic analysis model, and describes TAM, which deals with the analysis requirements of the tenants, SAM, an analysis and specification model for cloud services, and CQIM, a querying and inference model. Section IV introduces the proposed VCB based on the semantic analysis model. In addition, we present the VCB architecture. Section V describes an illustrative example and the implementation of our VCB for provisioning cloud services. Finally, Section VI provides some concluding remarks and identifies areas of future work.
II. RELATED WORK AND DISCUSSION
We investigated different CSBs to determine how the tenant requirements can be collected. Most of the companies investigated have similar approaches to collecting the tenant requirements. Representative companies include LIAISON [10], APPIRIO [11], and Accenture [12].
LIAISON interlocks a number of third-party cloud services and provides functions such as data integration, transformation, and management. It receives company requirements consisting of contact information (email address, telephone number) and brief comments.
APPIRIO’s requirement collection is divided into four parts, namely: (1) an Innovation Workshop, (2) Customer, People, and Technology Strategy, (3) Vendor Selection and Business Case, and (4) Deployment Planning/Readiness. The Innovation Workshop is conducted over a one- to two-week period to identify key challenges and business priorities. The Customer, People, and Technology Strategy is conducted over a three- to four-week period, and includes activities such as an environmental scan and functional pain points. Using this information, the Vendor Selection and Business Case proceed by examining strategy, needs, and vendor engagement. Finally, Deployment Planning/Readiness is conducted to identify any risks and prepare the cloud migration.
Accenture also collects its requirements through email and phone calls. After this collection, the cloud services are designed, implemented, and customized to fit the company.
As explained above, CSBs have a manual processing structure. First, the cloud tenants contact the CSB. Cloud domain experts then assist with the provisioning of the cloud services.
CSB frameworks include Service Level Agreement (SLA)-based CSB [13] and a cloud agency [14].
Badidi [13] proposed the SLA-based CSB, which focuses on Software-as-a-Service (SaaS) provisioning. The work details several management operations: identity and access management, policies management, SLA management, and service provisioning. However, this broker focuses on how the SLA can be managed and negotiated.
Venticinque et al. [14] proposed a cloud agency focused on SLA negotiation and management. The agency depends on
several agents that aim to manage cloud resources and services offered by various cloud projects [14]. The cloud agency intermediates between users and providers to negotiate the best SLA for both consumers and providers.
CSB-related research has generally focused on system aspects [13][14]. However, such research has mainly shown how an SLA can be applied to cloud service recommendation, rather than how the tenant requirements can be acquired and analyzed. Moreover, they have not presented a method for specifying a cloud service.
The primary differences between the related works and the VCB are our clear suggestions of how tenant requirements can be acquired and represented, how cloud providers can specify and register the cloud services they offer, and how the cloud services can be acquired by querying and inference. In addition, we provide a VCB architecture that reflects these concerns.
There are many CSB-related issues, such as service recommendation, handling SLAs, interoperability, migration, and security. In this paper, we focus on semantic analysis models and their use for service recommendations. We explain how the cloud services can be acquired using semantic analysis models. Our proposed VCB has many key features of a CSB, such as SLA, evaluation, and customization. Currently, we are implementing the VCB architecture presented in Section III, and are studying its feedback and evaluation mechanism. In addition, we are applying various cloud service domains such as CRM and Project Management. After a stable VCB prototype has been implemented and evaluation and feedback log files have been accumulated, we plan to conduct a quantitative evaluation.
We can compare our VCB with some related models. Table I lists the differences among CSB frameworks. We can see that our proposed architecture supports tenant-centric service provisioning more efficiently than other frameworks in terms of service recommendation aspects. From the tenants’ perspective, the VCB supports the registration of requirements. Providers specify and register various cloud services using SAM. In addition, the VCB recommends cloud services using CQIM based on the output from TAM and SAM, as described in Section III. In cases where tenants cannot find satisfactory services, our VCB supports service customization requests.
TABLE I. DIFFERENCES AMONG CSBS
Criteria VCB E.
Badidi [13]
S. Venticinque et al. [14]
Cloud service
type All SaaS SaaS, IaaS
Requirement collecting support O (Tenant model) X O (Registration module) Semantic technology usage O (CQIM, using SPARQL) X O (Ontology, not provided detailed mechanism) Service registration support O (SAM) X (not provided detailed model) X (not provided detailed model) Service customization support O (Customization decision module) X X 1023 1023 1023 1023 1023 1023 1023 1023
III. SEMANTIC ANALYSIS MODEL
The main stakeholders in the VCB are cloud service providers and the tenants using the cloud service. Tenants have requirements for their cloud services, and hope to receive services that satisfy their requirements. The tenants can register their requirements within the VCB, which interacts with many different cloud service providers to select appropriate services. To do so, the VCB analyzes the tenant requirements and service specifications. In addition, it offers a mechanism to query and infer appropriate services in a more intelligent manner. In this section, we describe TAM, SAM, and CQIM in detail.
A. TAM
TAM specifies the tenant profiles and requirements. It is used to distinguish one tenant from another, and obtain services based on tenant profiles and requirements. TAM standardizes the tenant representation, making such representations easy to store and manage, and providing a more appropriate service for the tenant. TAM was created using several previous models of Web and cloud service requirements [15][16].
Fig. 1 illustrates the metamodel of TAM. This module is composed of three aspects.
Fig. 1. TAM Metamodel
The first aspect is the tenant profile side, which has an identifier and a property. The profile includes login data for the VCB, such as the user’s ID, and some basic tenant properties including their e-mail address or contact information. Single-user information that is helpful for search services includes the user’s job, gender, financial status, and other properties. These data are applied to the search service and various means of finding a service. Corporation and community users also have specific information that is used to represent their properties. Such information includes the corporation’s number of employees, type of business, and business-scale information, whereas community information includes the number of members and community type.
The second aspect is the environment. The environment indicates circumstances in which the tenants connect to their VCB and cloud services. Because different environments have different types of connectivity, distinguishing them is very
important. TAM differentiates between operating systems (e.g., Windows, OS X, Android, iOS, and Linux) and browsers (e.g., Internet Explorer, Google Chrome, Mozilla Firefox, and Safari). These two environment elements are related to finding services, and determining the most appropriate data processing method and User Experience. In addition, the network status and region are important, because they determine how fast a tenant’s devices can interact with VCB and service providers. Services cannot work properly in certain regions where they are prohibited.
The final aspect concerns requirements. As a service is composed of features in VCB, a requirement has features that consist of an attribute, value, type, and description.
B. SAM
To provide tenants with cloud services, VCB systematically defines a structured model for analyzing and specifying the services provided by the cloud service providers. We present SAM as a basic specification model, a variability of a concept from software product line engineering (SPLE) in previous research.
SAM is a knowledge information model that supports the analysis and inference of various cloud services registered by service providers. In VCB, SAM provides cloud services to the tenants. Fig. 2 shows the metamodel of SAM, consisting of service and provider information. The provider information includes the name of the personnel or organization, contact information (such as their phone number, email address, and physical address), and online information (such as their homepage and SNS accounts).
The type of cloud service provided by VCB is divided into three parts: Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and SaaS. Each service has its own specifications and SLA. In VCB, the SLA is defined as “variable SLA” (VSLA), which is an agreement between tenants and the VCB, or between providers and the VCB, to identify and maintain a certain level of cloud services. A VSLA states the quality of service (QoS) and lease price. The pricing is determined depending on the type of cloud service offered.
In addition, there are differences in service specifications, because cloud services have different functional characteristics according to the form of delivery. The functional specifications for each type of cloud service are as follows:
1) IaaS
a) Infra: Infra includes virtualized hardware and integrated management software to connect tenants and resources.
b) Resource: Resources are constituents of the infrastructure, such as the compute, storage, and network. Compute resources have attributes such as the CPU capacity, RAM size, and virtual machine (VM) image. There are many compute services, e.g., EC2 from Amazon Web Service (AWS) and Google Compute Engine (GCE). Network resources provide network-related resources as a service, and are defined as the bandwidth and IP addressing. For example, Microsoft Azure provides network resources such as ExpressRoute, Virtual Network, and Traffic Manager. Storage resources are presented by the amount of storage space (GB).
1024 1024 1024 1024 1024 1024 1024 1024
Fig. 2. SAM Metamodel
Fig. 3. CQIM Ontology Model
1025 1025 1025 1025 1025 1025 1025 1025
2) PaaS
a) Environment: The environment indicates the platform for developing and deploying applications; for example, Google App Engine (GAE) provides a runtime environment for Python, Java, and PHP.
b) Application: An application is a program developed and deployed through the provided platform or framework. It has attributes such as basic information on applications executable on the platform, such as the application type, file capacity, and version.
3) SaaS
a) Interface: Interfaces are responsible for connecting external elements. In addition, many service providers and tenants are provided with access through an interface.
b) Operation: An operation is a function provided by the executable service, and is a unit of service desired by the tenants.
c) Message: Messages are divided into two types. One is input data for executing a service, and the other is output data after executing the service. For the common operation of various services, the input and output messages exchanged may be different.
C. CQIM
To infer and query appropriate cloud services, we define the CQIM semantic model, which is constructed using the web ontology language (OWL) [17]. OWL is endorsed by the World Wide Web Consortium, and is used when the information contained in a document needs to be processed by applications. OWL facilitates the expression of meaning and semantics to a high degree. Therefore, we use OWL to represent our query and inference model.
CQIM is used for inference and querying the cloud services in VCB. Fig. 3 shows the CQIM ontology and its specific ontology for a project management domain. Using the proposed CQIM as a basis, we can generate various specific domain CQIMs. CQIM comprises classes such as FR, NFR, User, and Service. FR denotes the functional features that comprise cloud service families, NFR represents non-functional features, User refers to an individual, group, or organization that uses cloud services, and Service denotes the cloud service that is queried or inferred by CQIM.
As shown in Fig. 3, we construct specific CQIMs for cloud service domains. Using the CQIM model, we can then query and infer cloud services. Table II presents SPARQL [18] query rules relating to cloud services with a Collaborative_Software functional feature.
TABLE II. SPARQLQUERY EXAMPLE
ID SPARQL Query
q-1
SELECT ?sub WHERE {
?sub rdfs:subClassOf [owl:onProperty :hasFR ; owl:someValuesFrom :Collaborative_Software]
}
SPARQL was defined as a standard by the RDF Data Access Working Group of the World Wide Web Consortium, and is recognized as one of the key technologies employed by the Semantic Web. Therefore, we use SPARQL as a querying and inference method for the CQIM ontology. Fig. 4 shows the results of a query implemented in the CQIM ontology using Protégé. In CQIM, the ObjectProperty relationship is denoted as hasFR; in addition, CQIM has the sub-class relationship.
Fig. 4. CQIM Query Result
As shown in Fig. 4, AceProject is a sub-class of the service class, and has a hasFR relationship with the Collaborative_Software feature, which is a sub-class of the FR class. Therefore, we can reason and query based on this relationship using the query written in Table II. The results are the AceProject and Teampage.
IV. ARCHITECTURAL PERSPECTIVE OF VCB A. Architecture
VCB has the ability to deliver cloud services to tenants while managing its own operational policy. Fig. 5 shows the conceptual architecture of VCB.
Fig. 5. VCB Architecture
This architecture consists of five layers containing several modules. These modules can be described as follows:
1026 1026 1026 1026 1026 1026 1026 1026
1) Access Interface Layer
a) Identification Module: When users log in to VCB, the system performs user authentication to control access and determine the user’s role within VCB.
b) Registration Module: All users have to join VCB to use it, and this entails entering basic information such as an ID and password. Tenants can input the requirements of the services they wish to use, and providers can register the specifications of services they want to provide.
c) Delivery Module: This module is responsible for delivering required information to the user. In this module, when a service that satisfies a tenant’s requirement is selected by the tenant, VCB delivers the service. Further, if service customization is needed, VCB will notify the customizer of that request, and deliver the specifications for candidate services. A customized service can also be delivered to the tenant.
2) Service Intermediation Layer
a) Service Inferencing Module: An inference engine employs ontological rules for the querying and inference of cloud services that meet the tenant’s requirements according to VCB’s internal policy and CQIM. VCB then filters appropriate services from the list of selected services, considering both the functional and non-functional specifications of those services.
b) Service Relation Discovery Module: VCB analyzes the usage patterns of services to discover the relations between them. VCB then identifies additional services that the tenant may use later.
c) Customization Decision Module: Tenants can submit requests for service customization to VCB when they are not satisfied with the list of services provided. To meet their requirements and improve tenant satisfaction, VCB determines which services can be customized in this module. That is, VCB identifies candidates for combination into a new service by the customizer.
3) Evolution Management Layer
a) Feedback and Evolution Module: VCB generates and manages an evolutionary model that provides feedback to improve service recommendations. This model incorporates cloud service usage patterns and the accuracy with which appropriate services are found. This evolutionary model provides a mechanism for updating the inference rules used to recommend appropriate services. To realize this, VCB tracks the log data of service recommendations and determines feedback information, allowing the module to improve VCB’s performance.
b) Evaluation Module: VCB evaluates cloud service offerings according to an internal operation policy. Provided services are evaluated according to whether they consistently conform to the SLA. Further, VCB ensures that the provider maintains the ability to provide their service. This module also sets any penalties for insufficient services based on their usage history and SLA violations.
4) Operation Support Layer
a) Resource Management Module: VCB manages resources such as catalogs, policies, and SLAs. The catalog includes details on tenants, providers, services, and so on. Cloud services are delivered to tenants by VCB, which updates and logs the usage of those services.
b) Contract Management Module: This module manages the contract created when providers register services or tenants use services. Contract management includes the maintenance and closure of contracts and other such functions. Examples of the details maintained on a contract include its duration and any fees to be paid in the event of its termination.
5) Semantic Analysis Layer
a) Tenant Analysis Module: This module analyzes both the tenant’s profile and requirements for services registered with the VCB to determine what services correspond to the tenant’s requirements.
b) Service Analysis Module: This module is responsible for identifying information regarding cloud services and their service provider. The VCB analyzes whether it is possible for services to be provided to tenants according to the internal operating policy of the VCB, and formulates a VSLA contract.
c) Record Analysis Module: This module analyzes the historical records and statistical information regarding the use, query, and inference of services in VCB. That is, it identifies the tenant’s purpose, frequency of service use, and query or inference ratio, and then calculates the tenant’s satisfaction with the service based on log data recorded in VCB.
B. Module Interaction
As shown in the system architecture, we define the relationships and interactions between certain modules. Fig. 6 shows the data flow among modules when delivering a service to a tenant. When the tenant logs in and sends their requirements to VCB, the Identification and Registration modules process the requests. The requirement information is stored in a catalog by the Catalog Management module. This module requests the Service Inferencing module to find services that satisfy the catalog of tenants and their requirements. At this time, the modules in charge of analysis (such as the Tenant Analysis, Service Analysis, and Record Analysis modules) find the tenant information and obtain the service information. The analysis results are then sent to the Service Inferencing module, which determines the most appropriate services using CQIM. These services are filtered for provisioning, enabling their use by the tenants. Before the tenants use a selected service, they need to enter into a contract with VCB, and thus the Delivery module connects to the VSLA Management module to deliver information regarding the contract negotiations. Finally, the service is delivered to the tenant when the negotiations are completed by the VSLA. During and after service delivery, VCB saves the usage report and evaluates its own usage to subsequently provide better services. 1027 1027 1027 1027 1027 1027 1027 1027
Fig. 6. Interaction with VCB Modules
V. ILLUSTRATIVE EXAMPLE AND DISCUSSION A. Scenario
In this section, we illustrate the processes of service registration and service recommendation. The following scenario, illustrated in Fig. 7, describes the process of registering a service by a service provider.
Fig. 7. Flow of Service Provisioning
Smith is the marketing manager of a corporation that provides IaaS services. He has learned that the use of VCB is a good way to improve his sales performance, and would like to register with VCB. Smith joins and logs into VCB. After registering his service on VCB, Smith inputs the service specifications using a service registration template. This template includes the provider’s basic information (e.g., name, type, phone number, and e-mail address), basic service information (e.g., service name, type, domain, and description), and type of service.
VCB checks the specifications and decides whether to register the service. An admitted service is registered in VCB, which establishes a contract with Smith by negotiating with a VSLA. As shown in Fig. 8, the service specification is stored
in the catalog. If the service does not allow registration, the VCB signals this information to Smith.
Fig. 8. Service Specifications of Microsoft Azure
In the following scenario, we describe the process of obtaining a recommendation for an IaaS. Currently, Mark finds appropriate services by contacting different providers through phone calls, e-mails, and the Internet. However, it is difficult for Mark to compare the price and performance of each service, because there are numerous IaaS types available. Mark identifies VCB through a CSB, and chooses to receive a service recommended by VCB.
Mark accesses VCB to obtain a recommendation of any IaaS, and submits his basic information and requirements in accordance with the template provided. VCB then infers what services are appropriate by analyzing the tenant’s information and requirements based on the corresponding ontology. VCB presents the inference results satisfying the most similar conditions to Mark’s requirements in a regular sequence, and describes the service specifications (e.g., price and degree to which they match the tenant’s requirements).
At this point, if the type of service required by Mark does not exist on the list of recommended services, Mark can demand a customized service. If a service customization is requested, VCB asks a service customizer to produce a service that matches the tenant’s requirements. The service customizer registers their customized service after completing the development, and VCB then notifies this to Mark, who checks the completed service. If satisfied, Mark enters into a contract with VCB to use the service. After the service has expired, Mark can evaluate the service as high, medium, or low quality. VCB then refers to Mark’s evaluation results when recommending the same service to other tenants.
B. Prototype Implementation
We implemented a prototype VCB. Fig. 9 shows the user interface on which tenants register their requirements after
1028 1028 1028 1028 1028 1028 1028 1028
logging into VCB. Using this screen, the tenant inputs their service requirements. VCB then recommends a service based on these requirements.
Fig. 9. User Interface of Requirement Registration
Fig. 10. User Interface of Service Recommendation
Fig. 10 shows the VCB service recommendation screen that is displayed after analyzing the tenant’s requirements. These results are based on querying and inference using CQIM. As Fig. 10 shows, tenants can apply for a customization if they judge that the services offered do not meet their requirements.
VI. CONCLUSION
With the diversification of cloud services and the emergence of those with similar functions, the role of a CSB to intermediate cloud services that fit the requirements of various tenants is increasingly important.
To enable CSBs to provide proper cloud services based on tenant requirements, we have proposed the use of VCB. In this paper, we described the use of TAM to collect and analyze the
tenant requirements. We also described SAM, which specifies and analyzes the various types of cloud services, and an ontology model called CQIM for cloud service querying and inference. Using these models, we proposed the VCB architecture, and explained how this can be applied for the recommendation of cloud services. Our proposed models and VCB enable the tenant-centric provisioning of cloud services. In addition, the VCB architecture provides a reference for other CSBs. In future work, we will define the SLA process for a VCB, and propose a mechanism for the systematic management of cloud services.
REFERENCES
[1] Y. Gong, Z. Ying, and M. Lin, “A Survey of Cloud Computing”, Proceeedings of the 2nd International Conference on Green Communications and Networks, Vol. 3, Lecture Notes in Electrical Engineering, pp. 79-84, 2013.
[2] R. Vozmediano, R. Montero, and I. Liorente, “Key Challenges in Cloud Computing Enabling the Future Internet of Servcie,” IEEE Internet Computing, Vlo. 17, Num. 4, pp.18-25, 2013.
[3] D. Puthal, S. Mishra, and S. Swain, “Cloud Computing Features, Issues and Challenges: A Big Picture”, International Conference on Computational Intelligence and Networks, pp.116-123, Jan. 2015 [4] Gartner, http://www.gartner.com/technology/home.jsp
[5] R. Bohn, J. Messina, F. Liu, J. Tong, and J. Mao, “NIST Cloud Computing Reference Architecture”, NIST Special Publication, Jul. 2011
[6] D. Morrison, “The evolution of cloud service brokerage”, http://www.huawei.com/en/static/HW-193390.pdf, Sep. 2012
[7] B. Wadhwa, A. Jaitly, and B. Suri, “Cloud Service Brokers An emerging trend in cloud adoption and migration”, Asia-Pacific Software Engineering Conference, pp. 140-145, Dec. 2013.
[8] P. Pawar, M. Rajaraja, T. Dimitrakos, and A. Zisman, “Trust Assessment Using Cloud Broker”, Trust Management VIII, IFIP Advances in Information and Communication Technology, Vol. 430, pp. 237-244, Jul. 2014
[9] B. Wadhwa, A. Jaitly, N. Hasija, and B. Suri, “Cloud Service Brokers: Addressing the New Cloud Phenomenon”, Informatics and Communication Technologies for Societal Development, pp. 29-40, 2015
[10] LIAISON, http://liaison.com/ [11] APPRIO, http://www.apprioinc.com/
[12] Accenture, http://www.accenture.com/us-en/pages/index.aspx [13] E. Badidi, “A Cloud Service Broker for SLA-based SaaS Provisioning”,
International Conference on Information Society, pp. 61-66, Jun. 2013 [14] S. Venticinque, R. Aversa, B. Martino, M. Rak, and D. Petcu, “A Cloud
Agency for SLA Negotiation and Management”, Euro-Par 2010 Parallel Processing Workshops Lecture Notes in Computer Science, Vol. 6586, pp. 587-594, 2011
[15] Y. Joung, M .Zarki, and R. Jain, “A User Model for Personalization Services”, International Conference on Digital Informaion Management, pp. 1-6, Nov. 2009
[16] A. Figueora and R. Ramirez, “Developing applications for autistic users: Towards an autistic user model”, International Conference on Cloud & Ubiquitous Computing & Emerging Technologies, pp. 228-235, Nov. 2013
[17] OWL (Web ontology language), W3C recommendation, http://www.w3.org/2004/OWL
[18] SPARQL Query Language for RDF, W3C recommendation, http://www.w3.org/TR/rdf-sparql-query/ 1029 1029 1029 1029 1029 1029 1029 1029
