Virtual Cloud Bank: An Architectural Approach for

Intermediating Cloud Services

Joonseok Park

Youngmin An

Keynhyuk Yeom*corresponding author

Research Institute of Logistics

Innovation and Networking
Pusan National University
Busan, Korea
pjs50@pusan.ac.kr

Department of Electrical and

Computer Engineering
Pusan National University
Busan, Korea
aym41@pusan.ac.kr

Department of Computer Science

Engineering
Pusan National University
Busan, Korea
yeom@pusan.ac.kr

AbstractWith the recent advent of the cloud computing

paradigm, the concept of a cloud service broker (CSB) is rapidly
emerging. The general role of the CSB is to intermediate cloud
services. However, to adopt and realize this concept, we need to
identify the primary stakeholders, define key requirements, and
define the overall structure of the CSB. It is these architectural
concerns on which the present paper is focused. We propose a
CSB we refer to as the virtual cloud bank (VCB). It
intermediates tenant-centric cloud services that fulfill the
requirements of tenants. We also define the stakeholders, their
requirements, and the architecture of VCB. VCB is proposed in
part for wider use as an architectural template and base model
for the realization and adoption of CSBs within a cloud
computing paradigm.
Keywordscloud computing; cloud service brokerage; cloud
service; cloud service intermediation; virtual cloud bank

I.

INTRODUCTION

Recently, the dominance of the pc-centric paradigm has

shifted to the paradigm of cloud computing. In the cloud
computing paradigm, cloud consumers referred to as tenants
rent cloud services such as software as a service (SaaS),
infrastructure as a service (IaaS), and platform as a service
(PaaS). The growing diversity of cloud services and providers
is indicative of the expansion of cloud computing. In addition,
requests for cloud services that fit the specific requirements of
tenants are multiplying. We therefore need the means to
intermediate the provision of cloud services.
The concept of cloud service brokers (CSBs) appeared
according to this tendency of cloud computing. Research on
CSBs is ongoing and has relevance for the adoption and
growth of cloud computing. Many definitions for CSBs have
been proposed [1][2]. The business type and concept of CSB is
presented by the Gartner and NIST [3][4]. A variety of
commercial and technical issues inherent to CSBs are being
addressed [1]. However, work on architectural approaches to
cloud service brokerage remains scarce. In terms of software
engineering, architectural research provides a basis for
This work was supported by the National Research Foundation of
Korea(NRF) grant funded by the Korea government(MSIP) (No. NRF2013R1A2A2A01068256) and the Ministry of Education (No. NRF2014R1A1A2007061).

978-1-4799-8676-7/15/$31.00 copyright 2015 IEEE

SNPD 2015, June 1-3 2015, Takamatsu, Japan

communication,
formation [5].

mutual

understanding,

and

consensus

Therefore, research on the architectural aspects of cloud

service brokerage is needed to initiate and realize the concept
of the CSB. In other words, we need to identify the
stakeholders that would interact with a given CSB, articulate
their requirements, and propose an architecture for that broker.
In this paper, we propose a tenant-centric CSB dubbed the
virtual cloud bank (VCB), intended to deliver cloud services
that fulfill tenants actual requirements. The contribution of our
research can be summarized as follows:
1.

Identification of key stakeholders that would interact

with VCB

2.

Suggestion of requirements for VCB

3.

The conceptualization of an architecture for VCB

The rest of this paper is organized as follows. The next section

outlines the basic concept of cloud service brokerage. Section
III describes related work. Sections IV and V presents our
architectural concept for VCB and an illustrative example.
Section VI concludes the paper, presents discussions and
describes future work.
II.

BASIC CONCEPT

A. Cloud Computing and Cloud Services

Cloud computing is defined by the U.S. National Institute
of Standards and Technology (NIST) as a model for enabling
convenient, on-demand network access to a shared pool of
configurable computing resources that can be rapidly
provisioned and released with minimal management effort or
service provider interaction [6]. A user with an internetenabled device such as a PC, smartphone, or tablet can use
available cloud services whenever desired. These services are
provided in three types [7]:
y IaaS involves outsourcing the equipment used to
support operations, including storage, hardware,
servers, and networking components.

y PaaS is a paradigm for delivering operating systems

and associated services over the Internet without
downloads or installation.
y SaaS is a software distribution model in which
applications are hosted by a vendor or service provider
and made available to customers over a network,
typically the Internet.
B. CSB
The role of a CSB is to act as an intermediary between
consumers and cloud service providers. The CSB recommends
services to consumers (rather than the service provider) and
consumers can use the services provided by the CSB. NIST
defines the classification of CSBs as follows [8]:
1)
Service Aggregation: A cloud broker combines and
integrates multiple services into one or more new services. The
broker provides data integration and ensures secure
transmission of data between the cloud consumer and multiple
cloud providers.G
2)
Service Intermediation: A cloud broker enhances a
given service by improving some specific capability and
providing value-added services to cloud consumers. The
improvement can be in the management of access to cloud
services, identity management, performance reporting, security
enhancement, etc.G
3)
Service Arbitrage: Service arbitrage is similar to
service aggregation except that the services being aggregated
are not fixed. Service arbitrage means a broker has the
flexibility to choose services from multiple agencies. The cloud
broker, for example, can use a credit-scoring service to
measure and select an agency with the best score.

detailed architectural elements of a CSB.

A proposed service provision ecosystem [9] outlines an
architecture that consists of four major elements, namely:
service developer, service provider, service broker, and service
consumer. In terms of cloud brokers, the conceptual elements
this entails include application catalogs, self-service
entitlement, role-based access control, SLA monitoring, billing
and metering, and reporting and auditing. The detailed role and
meaning of these elements is not provided.
Further, there exist frameworks for CSB such as the SLAbased CSB [10], cloud agency [11], and the semantic broker
[12].
Badidi [10] proposed the SLA-based CSB. This broker
focused on SaaS provisioning based on a SLA. 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. [11] proposed a cloud agency. This
broker focused on SLA negotiation and management. In
addition, the agency depends on several agents that aim to
manage cloud resources and services offered by various cloud
projects [11]. Cloud agency intermediates between users and
providers in order to negotiate the best SLA for both
consumers and vendors.
Ngan et al. [12] propose OWL-s based semantic cloud
service discovery and selection system. This broker takes a
semantic approach, and the authors detail a system architecture
that consists of semantic service repository, matchmaker, and
service selection. They focus on the process of finding a
matched service using semantic technologies.
IV.

III.

RELATED WORK

NIST suggests a cloud computing reference architecture

that consists of five major elements, namely: cloud consumer,
cloud auditor, cloud broker, cloud provider, and cloud carrier
[8]. In terms of cloud brokers, this schema yields only the types
of CSBs that denote service intermediation, service
aggregation, and service arbitrage. It does not provide the

ARCHITECTURAL PERSPECTIVE OF VCB

A. Stakeholder and Role

Fig. 1 shows the conceptual model of VCB and its
relationship with stakeholders. It consists of four parts, each
associated with a distinct role: tenant, provider, administrator,
and customizer. Each role is defined by its business
relationship with VCB. The stakeholders associated with these

FIG. 1. CONCEPTUAL MODEL FOR STAKEHOLDER AND VIRTUAL CLOUD BANK

roles are explained in detail as follows:

1)
Tenant: a VCB user who finds and uses cloud
services. The tenant can be a person, organization,
community, or anyone who wants to use a cloud service.
Tenants register their service requirements and receive
services as a result. When a tenant uses a service, he/she is
responsible for paying any fee for service. If a tenant is
dissatisfied with a received service, they can submit a request
for service customization to make a new service that meets
their requirements.
2)
Provider: a person or corporation that provides one
or more services for tenants. Providers make services and
register their specifications with VCB. Tenants can get
recommendations for registered services on the basis of
his/her stated requirements. As a tenant purchases services, the
provider can develop a business relationship with the tenant
and can charge a fee for the service via VCB. The provider
then receives service evaluations, usage statistics, and so on.
3)
Administrator: a person who manages and helps
adapt VCB. When an administrator receives a management
and error report from VCB, he/she may take a variety of
actions including policy modification, provider management,
and/or the grading of tenants or services in order to manage
the whole of VCB and the services deployed in VCB. The
administrator is also responsible for warning the service
provider if the quality of service (QoS) is not being sustained
or the system suffers a critical error. If warnings on a specific
service are stacked, the administrator can discard that service.
4)
Customizer: a person or corporation who
compounds several services. If a tenant is not satisfied with
the suggested services from the VCB, the tenant can request to
make combined or upgraded service. This requirement is
delivered to the customizer via VCB. The customizer then
creates a new service that meets the tenants requirements.
This sequence is called cloud service aggregation. After
service aggregation, the customizer registers to the new
service with VCB to be used by the tenant who requested it.
Similar to the provider, the customizer also has a business
relationship with VCB. For example, the customizer can get
paid by the tenant via VCB for using and making a
customized service.
B. Functional Requirements
The functional requirements of VCB depend on the
stakeholders in cloud service intermediation. The
requirements for each stakeholder can be categorized as
follows:
1)
For a tenant
a) Provide an interface to register tenants
requirements: Requirements can be functional in nature but
may also include non-functional requirements such as
availability, security, and pricing. Tenants register
requirements for the service they need with the VCB, which
analyzes and maintains them.

b) Report historical usage data and SLA compliance:

Tenants can check their usage of services, and monitor
contracts with the VCB to which they have agreed. Contracts
are also known as Service Level Agreements (SLA), but both
terms refer to a negotiation between the cloud service provider
and the tenant that includes quality metrics, pricing, and
contract information.
c) Select service among multiple services from
providers: There are many types of services provided by
multiple providers. When the requirements of the tenant are
entered, VCB promptly identifies services that satisfy those
requirements and provides a list of selected services to the
tenant.
d) Deliver a selected service from a tenant: As
mentioned above, VCB is responsible for selecting a set of
cloud services that satisfy tenants requirements. Tenants
select a service that they want to use from the list of services
provided by VCB, which then promptly delivers them to
tenants.
e) Conclude contract with VCB: In the traditional case
without any CSB, tenants make contracts for cloud services
directly with a provider, but here, tenants use cloud services
through contracts with VCB, not with providers.
2)
For a provider and a customizer
a) Register their service specification: Providers
register detailed specifications for the services they provide.
Customizers can be considered a kind of provider, albeit one
who creates a combination of two or more services. Therefore,
customizers also register their services specifications in the
same manner as general providers.
b) Evaluate and monitor their services to ensure SLA:
VCB evaluates whether services offered by providers and
customizers comply with the SLA and are provided without
intermittency.
c) Provide records about service provisioning: VCB
displays historical and statistical data on provided services,
such as usage, number of tenants employing the service, and
the term of any contract.
d) Provide service aggregation: If tenants are
dissatisfied with the list of services selected by VCB, they can
demand the aggregation of several services. VCB will then
prepare for service aggregation automatically.
3)
For an administrator
a) Provide authentication to access to VCB: a user
authentication mechanism is needed because the administrator
wants exclusive access to certain portions of VCB. In
particular, only the administrator can modify VCBs policies
and resource management.
b) Provide policy management: Administrator manages
the internal policies for running VCB such as grades for
tenants, commission regulation, and the period for updating
VCB.
c) Provide resource management: VCB carries many
types of resources necessary for its operation, and these can be

managed exclusively by the administrator. For example, the

administrator can give providers a strict warning or discard
their services from the service catalog when their number of
violations exceeds a certain level of warning.
C. Architecture
VCB has the ability to deliver cloud services to tenants
while managing its own operation. Fig. 2 shows the conceptual
architecture of VCB. This architecture consists of four layers
that have several modules. Each of these modules are described
as follows:

VCB then filters appropriate services from the list of selected

services, considering both functional and non-functional
specification of those services.
b) Service Relation Discovery Module: VCB analyzes
the usage patterns of services to discover relations between
them. Then, VCB identifies additionally available services
that the tenant may use later.
c) Requirement Analysis Module: In the requirement
analysis module, VCB analyzes the features of services using
tenants requirements and historical data on usage.
d) Customization Decision Module: Tenants can submit
requests for service customization to VCB when they are not
satisfied with the list of services VCB provides. To meet their
requirements and improve satisfaction, VCB decides services
can be customized in this module. That is, VCB identifies
candidates for combination into a new service made by the
customizer.
3)
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 usage of those services.

FIG. 2. ARCHITECTURE OF VCB

1)

Access Interface Layer

a) Identification Module: When users log in to VCB,
the system performs user authentication to control access and
determine the users role within VCB.
b) Registration Module: All users have to join VCB to
use it, and this entails entering basic information such as ID
and password. Tenants can input requirements for services
they wish to use and providers can register the specifications
for 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 tenants requirement is selected
by that 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 Brokerage Layer
a) Service Inferencing Module: An inference engine
employs ontological rules to select cloud services that meet
the tenants requirements according to VCBs internal policy.

b) Contract Management Module: This module

manages the contract created when providers register services
or tenants use services. Contract management includes
maintaining and closing a contract 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.
4)
Evolution Management Layer
a) Feedback and Evolution Module: VCB generates and
manages an evolutionary model for providing feedback used
to improve service recommendation. Patterns of cloud service
usage and the accuracy with which proper services are found
are incorporated into this model. 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 recommendation and determines
feedback information allowing the module to improve VCBs
performance.
b) Evaluation Module: VCB evaluates cloud service
offerings according to an internal operation policy. Provided
services are evaluated according to whether they remain in
conformance with the SLA. Further, VCB ensures that the
provider consistently maintains the ability to provide their
service. This module also sets any penalties for insufficient
services based on their usage history and SLA violation.
V.

ILLUSTRATIVE EXAMPLE

Fig. 3 shows the basic flow of tenant use, depicting the

relationship between activity and module, from joining VCB to
its use and service.

VI.

CONCLUSION

With the rapid expansion of the cloud computing paradigm

and the growing number of tenants, cloud services and cloud
providers are demanding a means for finding and delivering
appropriate cloud services. To support this cloud service
intermediation between providers and tenants, the concept of
the CSB has emerged as a solution.
In this paper, we focused on the architectural concerns of
the CSB. We have presented a CSB architecture called VCB,
enumerating both stakeholders and architectural requirements.
In addition, we suggested how the VCB can be applied to the
real world problem of cloud service intermediation with an
example. Furthermore, we compared our approaches with that
of other CSBs.

FIG. 3. FLOW OF CLOUD SERVICE RECOMMENDATION FOR TENANT

In the rest of this section, based on the above flow, we

consider an example of VCB use. Lily is a member of a
corporation that wants to use cloud CRM service, but the
corporation is having difficulty selecting the proper CRM
service because there are too many services to choose from.
After joining VCB as an organization member, Lily entered
the requirements of the CRM service, including features such
as sales management and product management (as
functions) and performance and price (as non-functions).
After Lily entered these requirements, VCB makes internal
inferences and matches the services with the requirements
using ontology. Then, VCB gives Lily a list of CRM services.
If Lily can find the service that she wants on the list of
servicesSalesforce CRM, for exampleshe can contract
with VCB, which will work as a mediator between Lily and the
service provider, helping them fulfill their contract and pay any
fee.
However, if Lily cannot find what she wants, she can
request service customization. No single service meets all of
Lilys requirements. In this case, she requests a new service be
made that meets her requirements (e.g., member
management) based on Salesforce CRM (assuming for the
sake of argument that it does not provide member
management). By combining two or more services together
with an interface provided by the customizer, she can obtain an
integrated service that supports all of her requirements. Further,
this newly created service is registered to VCB so that other
tenants also can use that service.
After the contract is established, Lily can use the service.
While using a contracted service, she can estimate with grading
it and verify that the service obeyed the SLA. If she had some
problems or was inconvenienced while using the service, she
can report this to VCB, whereupon the administrator will
handle the problem.

The primary focus of our proposed VCB is its use for

intermediation and its provision of tenant-centric cloud
services. A primary difference between related works and ours
is our clear definition and description of architectural concerns.
We have identified the key stakeholders that interact with VCB.
In addition, we explicitly defined the key functions relating key
stakeholders. Finally, we proposed a layered VCB architecture
that consists of an access interface layer, a service brokerage
layer, an operation support layer, and an evolution
management layer.
We compared these previous works with VCB. Table 1
shows the differences among these service brokers.
TABLE I.

DIFFERENCES AMONG CSBS

VCB

E.
Badidi [10]

S.
Venticinque
et al. [11]

D. Ngan
et al. [12]

Cloud service
type

All

SaaS

SaaS, IaaS

IaaS

Monitoring

SLA,
Resource,
Service,
Policy

SLA,
Resource

SLA,
Resource

None

Criteria

Finding
services with
Ontology
Service
customization
Service
evaluation
Feedback and
evolution

Currently, we are designing the operation algorithm of

VCB. In future work, we will build VCB based on the
proposed architecture.
REFERENCES
[1]

[2]
[3]

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
S. Somashekar, Opportunities for the Cloud in the Enterprise, Product
Startegy White Paper, 2010
Gartner, http://www.gartner.com/it-glossary/cloud-services-brokeragecsb

[4]

[5]
[6]
[7]
[8]

R. Bohn, J. Messina, F. Liu, J. Tong, and J. Mao, NIST Cloud

Computing Reference Architecture, NIST Special Publication, Jul.
2011
L. Bass, P. Clements and R. Kazman, Software Architecture in
Practice, Addison-Wesley, 1998
NIST Cloud Computing Program, http://www.nist.gov/itl/cloud/
SPI model, http://searchcloudcomputing.techtarget.com/definition/SPImodel, Feb. 2012
L. Badger, R. Bohn, S. Chu, M. Hogan, F. Liu, V. Kaufmann, J. Mao, J.
Messina, K. Mills, A. Sokol, J. Tong, F. Whiteside and D. Leaf, US
Government Cloud Computing Technology Roadmap Volume II
Release 1.0, NIST, Nov. 2011

[9]

D. Morrison, The evolution of cloud service brokerage,

http://www.huawei.com/en/static/HW-193390.pdf, Sep. 2012
[10] E. Badidi, A Cloud Service Broker for SLA-based SaaS Provisioning,
International Conference on Information Society, pp. 61-66, Jun. 2013
[11] 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
[12] L. Ngan and R. Kanagasabai, OWL-S Based Semantic Cloud Service
Broker, International Conference on Web Services, pp. 560-567, Jun.
2012