INTEROPERABILITY AND PORTABILITY OF CLOUD SERVICE

ENABLERS IN A PaaS ENVIRONMENT

David Cunha

1,2

, Pedro Neves

and Pedro Sousa

Portugal Telecom Inovac¸

ao, SA, 3810-106 Aveiro, Portugal

Centro ALGORITMI / Department of Informatics, University of Minho, 4710-057 Braga, Portugal

Keywords:

Cloud Computing, Platform-as-a-Service, Portability, Service Delivery Platform, Context-awareness.

Abstract:

Nowadays, the competition in the telecommunications market is exciting and new entities with value-added

services have emerged over the core network of Telecommunications operators (Telcos). These new par-

ticipants have taken out the operators’ relevance since they are entirely agnostic from infrastructure service

connectivity. Therefore Telcos, like Portugal Telecom Inovac¸

ao (PTIN), need to focus on the provision of

services to a user’s point of view to not become just a dumb-pipe between the consumers and Cloud service

providers.

This paper proposes a deﬁnition of a distributed architecture that allows developers to create and expose ser-

vices through a Service Delivery Platform (SDP). The beneﬁt of such Cloud-enabled SDP architecture is the

portability of service enablers between Platform-as-a-Service (PaaS) providers through a standardized API.

Service developers may thus select the more suitable PaaS offering in order to build on-top applications, based

on the performance required by a service. An example of applications which can take advantage from more

versatile Cloud platforms, is the delivery of mobile context-aware services that react to both environment and

user conditions selecting the right type of content (e.g. photos, videos, etc.) to deliver.

1 INTRODUCTION

Cloud Computing introduced the concept of comput-

ing as a utility bringing an innovative and signiﬁ-

cant opportunity for operators in terms of new de-

livery’s models (on demand) and new ﬂexible busi-

ness strategies (B2B) (Armbrust et al., 2009). It al-

lows consumers and enterprises to use services over

the hardware and systems software hosted remotely at

providers’ datacenters. The analogy is, ”If you only

need milk, would you buy a cow?” (InternalCom-

puter, 2011). Therefore, to obtain the beneﬁt: making

video calls, sending emails, etc. the consumers really

need to acquire the required software/hardware? With

the Cloud Computing concept the answer is no. The

everyday needs of the general community can be de-

livered on a pay-per-use model with only a connection

to Internet, just like we do at home with the electric-

ity grid. All the software and hardware is provisioned

and governed by the Cloud services providers based

on the users’ requirements and so allowing a more ef-

ﬁcient computing (Zhang et al., 2010). It is thought

that one day Cloud Computing will be the 5th utility

(after water, electricity, gas, and telephony) (Buyya

et al., 2009), and it is currently a popular topic within

the academic research community.

A previous paradigm laid the foundations of

Cloud Computing with the principles of service ori-

entation. Service-oriented architecture (SOA) facili-

tates the design, reusability, deployment and manage-

ment of extendable applications towards interopera-

ble services (Azeez et al., 2010), (K.Ramana et al.,

2011). Nowadays, Web Services became the prevail-

ing SOA implementation paradigm over standard In-

ternet protocols (Blum et al., 2009). Applications can

be developed as compositions of service enablers dis-

tributed through a Service Delivery Platform (SDP)

exchanging data with each others. Cloud Comput-

ing embraced all these technologies creating a new

and promising landscape for a next generation of

SOA deployment. Cloud delivery models generally

fall in three categories: Infrastructure-as-a-Service

(IaaS), Platform-as-a-Service (PaaS), and Software-

as-a-Service (SaaS), but only higher Cloud stack lev-

els, such as, SaaS and PaaS will be discussed in this

paper. For NIST (U.S. Government’s National In-

stitute of Standards and Technology), it can be as-

sumed that with SaaS the consumer uses an applica-

432

Cunha D., Neves P. and Sousa P..

INTEROPERABILITY AND PORTABILITY OF CLOUD SERVICE ENABLERS IN A PaaS ENVIRONMENT.

DOI: 10.5220/0003959204320437

In Proceedings of the 2nd International Conference on Cloud Computing and Services Science (CLOSER-2012), pages 432-437

ISBN: 978-989-8565-05-1

 2012 SCITEPRESS (Science and Technology Publications, Lda.)

tion but does not control the operating system, hard-

ware or network infrastructure on which it’s running.

On the other hand with PaaS, the developer uses a

hosting environment Service Execution Environment

(SEE)/Service Creation Environment (SCE) for con-

trolling his services (life cycle) but does not control

the operating system, hardware or network infrastruc-

ture on which they are running (NIST, 2011). Under-

lying these concepts exist ﬁnancial incentives that at-

tract the both sides: Cloud service providers and con-

sumers, such as enterprises. Service providers charge

consumers for the delivery and governance of ser-

vices, and enterprises reduce both Capital Expendi-

ture (CAPEX) and Operational Expanditure (OPEX)

since there is no infrastructure provisioning or soft-

ware investment to be made at the beginning (Maes,

2010),(Armbrust et al., 2009). Telecommunications

operators (Telcos) are interested in taking a share of

this Cloud market where only some giants US ser-

vice providers, namely Google, Microsoft, Amazon

and Apple take the lead. To enter the game, op-

erators must exploit their differentiated assets (SDP,

OSS/BSS, CRM, service enablers, etc.) enabling a

two-sided business strategy with service providers.

With the emergence of numerous providers, the

need for interoperability and portability between plat-

forms (PaaS) will enable ﬂexibility for Third-parties’

developers. Increasing the Cloud choice will re-

duce the vendor ”lock-in” to speciﬁc technologies,

such as programming models, software tools or APIs

(Parameswaran and Chaddha, 2009),(Dikaiakos et al.,

2009). Telcos can explore these potentialities through

a Service Delivery Platform that glue the pieces to-

gether no matter where they are deployed (Bozman

and Chen, 2010). Then, they can sell their service en-

ablers to Third-parties for build-on top applications’

in order to play new roles in the Internet value chain.

In this context, this work proposes and explains a

Cloud-enabled SDP architecture that will simplify the

development of services in view to rapidly respond to

consumers’ needs with the migration of enablers be-

tween PaaS providers. Therefore, this paper presents

the related work (Section 2), the architecture speciﬁ-

cation toward a solution (Section 3), a possible use-

case in a real mobile environment (Section 4), and the

preliminary conclusions (Section 5).

2 RELATED WORK

Recently, some of the Cloud Computing’s concerns

are associated to interoperability and portability be-

tween different providers (Parameswaran and Chad-

dha, 2009),(Dikaiakos et al., 2009). It should be pos-

sible for developers to swap enablers between plat-

forms whenever they need (performance issues, ac-

tual costs, etc.) without re-architecting the solutions.

This can be a quite challenging with the different

data models and proprietary runtime frameworks that

each application requires and each provider enables.

Currently there are no standards for interoperabil-

ity or data portability, however some initiatives have

emerged from non-proﬁt groups with the collabora-

tion of researchers and some Cloud service providers.

The Open Cloud Manifesto (OCM, 2010) is an

initiative supported by various vendors with the vi-

sion to standardize Cloud Computing (interoperabil-

ity, portability, security, governance and management,

etc.). The goals of an open cloud, such as, ﬂexibility,

speed and agility, etc. are outlined to lead a discussion

about new cloud computing paradigms and impacts.

Another group, the Cloud Computing Interoperability

Forum (CCIF, 2009), proposes to unify Cloud APIs

with a standardized semantic interface (Uniﬁed Cloud

Interface) (UCI, 2009) and layers of abstraction from

the underlying infrastructure. The orchestration layer

and the federation of Clouds are the features of the

CCIF presented architecture. However, Amazon and

Microsoft rejected the CCIF agenda. Other initiatives

like OGF’s Open Cloud Computing Interface (OCCI,

2010) tries to bring, in a quick frame, an API speci-

ﬁcation for the deployment and monitoring. The cur-

rent release focus is in the Cloud infrastructures-as-a

service (IaaS), however, it is referenced that the model

may be suitable for higher interoperability at PaaS and

SaaS levels. The DMTF’s Cloud Management Work-

ing Group (CMWG, 2009) focus on deﬁning archi-

tectural semantics to standardize interfaces, interac-

tions and data formats between Cloud environments.

This body of work consists in the development of use-

cases, services life cycle, and an interoperable Cloud

architecture for service providers and their consumers

and developers.

In this perspective, it takes time for standards to

mature, and this lack of acceptance derives from the

disregard of providers like Google, Microsoft, Ama-

zon and others, that want to offer differentiated ser-

vices attracting more customers. On the other hand,

deﬁning standards in upper layers like PaaS and SaaS,

turns the normalization more dependent of propriety

interfaces.

3 TOWARD A SOLUTION

In this section, a Cloud-enabled architecture is pro-

posed clarifying the adopted strategy for the modules

integration and inherent development.

INTEROPERABILITYANDPORTABILITYOFCLOUDSERVICEENABLERSINAPaaSENVIRONMENT

433

Figure 1: Proposed Cloud-enabled SDP architecture.

3.1 Cloud-enabled SDP Architecture

The proposed Cloud architecture is presented in Fig-

ure 1 with a private PaaS (PTIN PaaS) and a public

PaaS.

At a very basic and abstract level, the SDP can be

seen as a collection of service enablers which are or-

chestrated by a Service Broker and exposed for third-

parties’ applications development in a SOA paradigm.

To consume the available services, the client only

needs to use the correspondent Web Services Descrip-

tion Language (WSDL) provided by the Service Bro-

ker, which in turn use remote invocation procedure

via Simple Object Access Protocol (SOAP) or Rep-

resentational State Transfer (REST) protocols. Fur-

thermore, the Service Broker is a middleware respon-

sible for tasks such as authentication, authorization,

accounting, binding, data transformation, load bal-

ancing, monitoring, policies and routing, between de-

ployed services and ﬁnal consumers. The service en-

ablers may be implemented using any type of technol-

ogy (Java, Python, PHP, Ruby, C#, Visual Basic, etc.),

as long as they are able to communicate with the Ser-

vice Broker via Web services. Third-parties’ devel-

opers interact with the Broker through the Developer

Interface

gaining access to the capabilities offered by

the SDP (i.e. the enablers). Then, the permissions re-

quired for exposing or managing developed services

will be assigned in order to choose the suitable PaaS

or deploying an enabler. Afterward, if the developer

wishes to change any enabler to another PaaS, the De-

veloper Interface will allow him to do so. The PaaS

Manager is the key element from the architecture pro-

viding the features required for a more ﬂexible and

interoperable PaaS environment. This module will be

more detailed in section 3.2.

Wizard platform for service’s deployment, migration

and management

Figure 2: Integration overview.

3.2 Integration Overview

The integration overview presented in Figure 2 focus

on the main components of the architecture: the De-

veloper Interface, the PaaS Manager, the Service Bro-

ker and the various platforms offering. As mentioned

above, the Service Broker has the registration of all

available services at the SDP. Querying this compo-

nent, it is possible to access the list of services and ob-

tain the WSDL that describes each one. For example,

when a service is called by a consumer, the Service

Broker will invoke the actual service logic which runs

in a PaaS environment. The PaaS Manager acts as

a standard implementation in order to integrate PaaS

offerings with the Developer Interface, allowing the

deployment and the portability of service enablers be-

tween platforms. Therefore, it is designed with each

PaaS APIs implementations which are used for con-

trolling all the offered functionalities. The interoper-

ability between providers can be reached through the

PaaS Manager and the Service Broker when a devel-

oper manages enablers that are deployed across di-

verse Clouds.

3.3 PaaS Manager Developer-cases

In this section the service registration and service mi-

gration processes are now overviewed within the pro-

posed architecture.

3.3.1 PaaS Manager Service Registration

Delving into more technical details, adding a new

service to the SDP involves supplying the PaaS Man-

ager with the business logic (i.e. the service code)

and the interface of the service (i.e. an Extensible

Markup Language (XML) ﬁle). The XML interface

schema will be handed to the Service Broker, which

will register the new service at the SDP. The PaaS

Manager component will then deploy the supplied

service code at the chosen platform. The ﬁnal

consumer’s applications use the WSDL to invoke

the service, while the Service Broker invokes the

CLOSER2012-2ndInternationalConferenceonCloudComputingandServicesScience

434

Figure 3: PaaS manager service registration developer-case.

deployed service code. The deﬁned steps for the

1 Set the suitable PaaS (PTIN PaaS or public PaaS);

2 Deﬁne the interface (XML) and supply the service code

(e.g .jar);

3 Register service process at the PaaS Manager;

4 Register service process at the Broker;

5 PaaS Manager deploys the service enabler in PTIN PaaS;

5a Or PaaS Manager deploys the service enabler in a public

PaaS.

Figure 3 presents a developer-case of a registration

procedure involving the Cloud-enabled SDP architec-

ture components.

3.3.2 PaaS Manager Service Migration

The migration of a service can be quite a chal-

lenge. The automated behavior deﬁned requires the

un-deployment of the service enabler from the previ-

ous platform, the archive being saved in a temporary

repository by the PaaS Manager, and ﬁnally the de-

ployment in the new PaaS. Meanwhile, the modiﬁca-

tion is performed at the Service Broker where a new

mapping is created in order to locate the new endpoint

when the migrated service is called by a consumer ap-

plication.

The data migration (e.g. databases, etc.) be-

tween PaaS is currently a topic under consideration

in the proposed architecture. One possible approach

is merely migrate databases between providers that

offer the same technology, for example, MySQL to

MySQL, Oracle to Oracle, etc. Moreover, an ad-

ditional concern is the dimension size of the ser-

vices’ databases systems, since saving several Ter-

abytes of data in a temporary repository and forward-

ing it through the network could become a heavy task.

The deﬁned steps for the migration process are the

following (see Figure 4):

Figure 4: PaaS manager service migration developer-case.

1 Set the new suitable PaaS (PTIN PaaS or public PaaS);

2 Migration service process at the PaaS Manager;

3 Migration service process at the Broker;

4,5,4a,5a Transference service process from previous

PaaS, to a temporary GIT repository and ﬁnally to the

new PaaS;

6, 6a PaaS Manager deploys the service enabler in the new

platform;

Figure 4 presents a developer-case of service porta-

bility involving the Cloud-enabled SDP architecture

components.

4 CLOUD-ENABLED SDP

ARCHITECTURE USE-CASE:

CONTEXT-AS-A-SERVICE

Context-as-a-Service (CaaS) brings the opportunity to

use consumers’ generated information for selecting,

rate and delivers suitable content (e.g. photos, videos,

etc.) to themselves. These metadata can characterize

any consumer situation, such as, his position, gender,

along with social, music or movies interests. There-

fore, context-aware systems proves to be the future

of mobile Internet services for ﬁnding and grouping

users with common interests delivering the most ap-

propriate content (Gomes et al., 2010).

In this section, the proposed use-case shows the

ability of automatically selecting the right content to

the right people. Public Spaces may easily become

Smart Public Spaces by offering a variety of mobile

context-aware services that react to both environment

and user conditions. The proliferation of such ser-

vices can, in such cases, generate an overload at some

platforms and underlying infrastructures. In order to

preserve the adequate performance, the PaaS Man-

ager will allows developers to migrate the service’s

modules, keeping the process the more agnostic pos-

sible for the ﬁnal consumers. Figure 5 shows the pro-

posed Context-aware architecture integrated with the

INTEROPERABILITYANDPORTABILITYOFCLOUDSERVICEENABLERSINAPaaSENVIRONMENT

435

Figure 5: Context-as-a-Service architecture.

SDP’s Service Broker, a Platform-as-a-Service and a

set of java service enablers. It is important to mention

that in the deﬁned architecture some of the CaaS mod-

ules are located within the same platform. However, it

is the service developer that manages the deployment

location of these components.

Each CaaS module depicted in Figure 5 has fun-

cionalities that will be detailed brieﬂy:

Context Providers: expose interfaces for provid-

ing information to the Context Broker. Through those

interfaces the Providers register their availability and

capabilities in order to publish different type of re-

trieved information (e.g. points of interest, calendar,

preferences, presence, social, etc.) from a speciﬁc

user.

Context Broker: responsible for retrieving and

delivering information to the Context enablers. It

manages and discovers all the registered Context

Providers, like the SDP’s Service Broker does with

the service enablers, matching context elements and

storing the information received from the Context

Agents.

Group Manager enabler (GME): responsible for

identify, create and manage groups of users, deliver-

ing context information for further processing. The

GME receives the list of subscribed consumers, and

starts establishing groups based on conﬁgured condi-

tions (e.g. location, social preferences, sensors infor-

mation, presence, gender, etc.). All this group infor-

mation is notiﬁed to the CSE for the content selection

handling process.

Content Selection enabler (CSE): responsible for

deﬁning selection rules for the content’s ranking de-

ciding which better meets the conditions of a certain

user or groups of users. CSE creates a playlist of con-

tent and delivers it to the mobile application. This en-

abler can be more or less complex depending on the

multifaceted ranking rules developed.

Content Providers: interact with the consumers’

applications delivering the selected content from the

playlist (e.g. photos, videos, etc.) by a client.

Context Agents/Consumers: typically located on

the consumers portable devices updating client’ situ-

ation data from several sensors (e.g. location, prefer-

ences, presence, social, etc.) for further processing at

the Context Broker.

The context consumption is done through XMPP

(Extensible Messaging and Presence Protocol) on

a publish/subscribe model. XMPP runs on top of

TCP/IP protocol stack and it is considered a more in-

teroperable protocol compared to JMS (Java Messag-

ing Service), and a lightweight compared to SOAP

(XMPP, 2007),(Gomes et al., 2010). Figure 6 presents

the communication scheme.

Figure 6: Context Consumption.

5 PRELIMINARY CONCLUSIONS

Cloud interoperability and standardization efforts will

increase the quality and diversity of Cloud Comput-

ing solutions provided to ﬁnal consumers. The ability

of seamlessly migrate services between providers re-

duces the existent ”lock-in” towards the development

of ﬂexible business applications across platforms.

This paper presented an architecture that will simplify

the development and exposure of services in view to

rapidly respond to consumers’ needs with the migra-

tion of enablers between PaaS providers. However,

the databases migration is still under survey since

it imposes some dependencies at the PaaS Manager

and underlying network. For the architecture proto-

typing, it was exposed a speciﬁcation/development

approach with the technical requirements and so-

lutions. Currently a PT’ Service Delivery Plat-

form solution (Sapo-SDB, 2011) is under exploration

for the integration of services in a SOA paradigm.

CLOSER2012-2ndInternationalConferenceonCloudComputingandServicesScience

436

Moreover, context-aware services are being tested in

some platforms providers, namely, Red Hat’s Open

Shift (Open-Shift, 2011), Google App Engine (GAE,

2011), CloudBees (Cloud-Bees, 2011) and probably

a PTIN platform which is under development. The

java implementation, and detailed speciﬁcation of the

PaaS Manager, will be soon in progress to integrate

and accommodate ﬁrstly the PT’ SDP, and in a poste-

rior phase, the Developer Interface.

ACKNOWLEDGEMENTS

The work of P. Sousa was funded by FEDER, through

the program COMPETE and the Portuguese Foun-

dation for Science and Technology (FCT), within

the project FCOMP-01-0124-FEDER- 022674. A

partial prototype, namely the context-aware ser-

vices and the integration with the PT’ SDP, will be

demonstrated under the scope of the European ICT

project ”Cloud4SOA” (Contract-No. ICT-257953):

(Cloud4SOA, 2010).

REFERENCES

Armbrust, M., Fox, A., Grifﬁth, R., Joseph, A. D., Katz,

R. H., Konwinski, A., Lee, G., Patterson, D. A.,

Rabkin, A., and Zaharia, M. (2009). Above the

clouds: A berkeley view of cloud computing. Tech-

nical report, University of California, Berkeley.

Azeez, A., Perera, S., Gamage, D., Linton, R., Siriwardana,

P., Leelaratne, D., Weerawarana, S., and Fremantle, P.

(2010). Multi-tenant soa middleware for cloud com-

puting. In CLOUD ’10 IEEE 3rd International Con-

ference on Cloud Computing, pages 458 – 465, Mi-

ami, Florida, USA.

Blum, N., Magedanz, T., Schreiner, F., and Wahle, S.

(2009). A research infrastructure for soa-based service

delivery frameworks. In 5th International Conference

on Testbeds and Research Infrastructures for the De-

velopment of Networks and Communities, pages 1–6,

Washington DC, USA.

Bozman, J. and Chen, G. (2010). Cloud computing: The

need for portability and interoperability. Technical re-

port, Red Hat.

Buyya, R., Yeo, C. S., Venugopal, S., Broberg, J., and

Brandic, I. (2009). Cloud computing and emerging it

platforms vision, hype, and reality for delivering com-

puting as the 5th utility. Future Generation Computer

Systems, 25(6):599–616.

CCIF (2009). The cloud computing interoperability fo-

rum. Retrieved December 2011, from: http://

www.cloudforum.org/.

Cloud-Bees (2011). Cloud bees. Retrieved January 2012,

from: http://www.cloudbees.com/.

Cloud4SOA (2010). The cloud4soa initiative

(fp7). Retrieved December 2011, from: http://

www.cloud4soa.eu/.

CMWG (2009). Cloud management working

group. Retrieved December 2011, from: http://

www.dmtf.org/standards/cloud/.

Dikaiakos, M. D., Katsaros, D., Mehra, P., Pallis, G., and

Vakali, A. (2009). Cloud computing: Distributed in-

ternet computing for it and scientiﬁc research. IEEE

Internet Computing, 13(5):10–13.

GAE (2011). Google app engine. Retrieved January 2012,

from: http://code.google.com/appengine/.

Gomes, D., Goncalves, J., Santos, R. O., and Aguiar,

R. L. (2010). Xmpp based context management ar-

chitecture. In 2010 Workshop on Enabling the Fu-

ture Service-Oriented Internet (EFSOI), pages 1372 –

1377, Miami, Florida, USA.

InternalComputer (2011). Understanding what cloud com-

puting means and its advantages. Retrieved Decem-

ber 2011, from: http://www.internalcomputer.com/

understanding-what-cloud-computing-means-and-its-

advantages.computer.

K.Ramana, Krishna, T., Narayana, C., and Kumar, M. P.

(2011). Comparative analysis on cloud computing and

service oriented architecture. International Journal of

Advanced Research In Technology, 1(1):22–28.

Maes, S. H. (2010). Understanding the relationship between

sdp and the cloud. In The First International Confer-

ence on Cloud Computing, GRIDs, and Virtualization,

pages 159–163, Lisbon, Portugal.

NIST (2011). The nist deﬁnition of cloud comput-

ing. Retrieved November 2011, from: http://

www.csrc.nist.gov/publications/nistpubs/800-145/

SP800-145.pdf.

OCCI (2010). Open cloud computing interface. Retrieved

December 2011, from: http://occi-wg.org/.

OCM (2010). The open cloud manifesto. Re-

trieved December 2011, from: http://

www.openCloudmanifesto.org/index.htm/.

Open-Shift (2011). Red hat open shift. Retrieved January

2012, from: https://openshift.redhat.com/app/.

Parameswaran, A. V. and Chaddha, A. (2009). Cloud inter-

operability and standardization. SETLabs Brieﬁngs,

7(7):19–26.

Sapo-SDB (2011). Sapo service delivery broker. Retrieved

December 2011, from: http://sdb.sapo.pt/.

UCI (2009). Uniﬁed cloud interface. Retrieved December

2011, from: http://www.groups.google.com/group/

uniﬁedcloud/.

XMPP (2007). Xmpp extensions. Retrieved December

2011, from: http://xmpp.org/.

Zhang, Q., Cheng, L., and Boutaba, R. (2010). Cloud com-

puting: State-of-the-art and research challenges. In-

ternet Services and Applications, 1(1):7–18.

INTEROPERABILITYANDPORTABILITYOFCLOUDSERVICEENABLERSINAPaaSENVIRONMENT

437