Towards a Composition-based APIaaS Layer

Claudio Guidi, Saverio Giallorenzo and Maurizio Gabbrielli

Department of Computer Science and Engineering - DISI, University of Bologna, Bologna, Italy

Keywords:

Service-oriented Computing, Cloud Computing, API, Composition, SaaS, PaaS, APIaaS.

Abstract:

Application Programming Interfaces (APIs) are a standard feature of any application that exposes its func-

tionalities to external invokers. APIs can be composed thus obtaining new programs with new functionalities.

However API composition easily becomes a frustrating and time-costly task that hinders API reuse. The issue

derives from technology-dependent features of API composition such as the need of extensive documentation,

protocol integration, security issues, etc.. In this paper we introduce the perspective of the API-as-a-Service

(APIaaS) layer as tool to ease the development and deployment of applications based on API composition,

abstracting communication protocols and message formats. We elicit the desirable features of such a layer and

provide a proof-of-concept prototype implemented using a service-oriented language.

1 INTRODUCTION

Application Programming Interfaces (APIs) are a

standard feature of any application that exposes its

functionalities to external invokers. APIs can be com-

posed to create new applications at client or server

side. In the former case composition takes the form of

a mashup (Liu et al., 2007), whereas in the latter case

it is usually realized within a speciﬁc application. De-

pending on the desired result, developers choose for

a server- or client-side composition, although there

are some cases in which only a server-side application

can comply with the requirements of the project, e.g.,

: (i) the developer needs to publish the composition

as a new API; (ii) the composition has some strate-

gic value, therefore the developer does not want to

publish it as a readable script at client-side; (iii) APIs

could use API keys and other identiﬁcation data that

must remain private and/or pass only through certi-

ﬁed channels like VPNs or SSH; (iv) privacy policies

and national agreements might enforce a known, cer-

tiﬁed, and geographically restricted route for data; (v)

API contracts require the user to be part of a speciﬁc

federated network. For these reasons and since our

interest regards API composition and publication, in

this work we focus on server-side API composition.

Composition of APIs implies the choice of a set of

different technologies that span from the implementa-

tion language to the communication and serialisation

protocols used by the application. The choice on these

technologies it is very important since it strongly af-

fects development, deployment, and maintenance of

the project. In addition, it is not clear what long-

term implications could derive from the choice of a

speciﬁc set of technologies at design-time. In order

to clarify how technology could affect a server-side

API composition project, let us consider the exam-

ple of Fig. 1 which reports the architectural view of

a realistic application, dubbed PhotoBlog. PhotoBlog

manages the publication of photos and their captions,

translated in several languages, on various blogging

platforms. PhotoBlog derives from the composition

of three APIs: (i) image, for image handling (resize,

cut, etc.) and storage; (ii) translation, for the auto-

matic translation of captions; (iii) blogging, for pub-

lishing images and captions as posts. Moreover, Pho-

toBlog itself exposes its own APIs to client interfaces.

image

service

translation

service

blog

service

API

PhotoBlog

API

client

interface

compose

use

Figure 1: An example of composition of APIs.

Assuming T the technology chosen for the devel-

opment of the project, the typical implementation of

such a composition passes by the following phases:

• documentation analysis: the developer must un-

derstand the parameters of interaction of each API

with T . Documentation analysis usually consists

of reading the companion documentation issued

425

Guidi C., Giallorenzo S. and Gabbrielli M..

Towards a Composition-based APIaaS Layer.

DOI: 10.5220/0004948004250432

In Proceedings of the 4th International Conference on Cloud Computing and Services Science (CLOSER-2014), pages 425-432

ISBN: 978-989-758-019-2

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

by the API provider;

• API connection: the developer must include, or

develop by her own, speciﬁc libraries for T to

handle communication and serialisation protocols

with the composed APIs. Notably, each API could

require the support of a different protocol;

• development: the developer implements the com-

position in T , employing the speciﬁc patterns of

composition provided by T ;

• deployment: the administrator of PhotoBlog de-

ploys the application on a platform of a provider

which supports T . Convenience, diffusion, and

support for T is another strong concern which in-

ﬂuences its choice;

• maintenance and evolution: the developer has to

maintain the project up-to-date wrt new releases

of APIs. API updates could require upgrades of T

by either the administrator or the provider of the

platform, depending on the service-level agree-

ment.

Even in such a simple example as PhotoBlog,

composing APIs requires a lot of “boilerplate” work

to enable communication with the composed applica-

tions. This diverts the focus of the developer from

the core composition functionality to the creation of

a suitable environment for composition. In addition

such an environment requires an exhausting work of

maintenance.

What emerges from our brief analysis is that APIs

are a commodity of any application, especially when

deployed on the cloud, but the heterogeneity of pro-

tocols makes interacting with several applications an

unaffordable task, if compared to its yield. The costs

of setting a suitable environment easily overcome the

potential value of the composition and represent an

important drawback of programming web and cloud

applications. This fact highlights the strong need for

tools that enable efﬁcient development of heteroge-

neous APIs, either in the cloud or on the Internet in

general. However, to the best of our knowledge, cur-

rently there is no structured programming patterns nor

formal theories which deal with API server-side com-

position in a cloud environment.

In this paper we try to attack this problem by

introducing the notion of an API-as-a-Service (API-

aaS) layer as a tool which eases the development and

deployment of applications based on API composi-

tions. By doing this, we also elicit the desirable gen-

eral features of such a layer. Moreover, we also pro-

vide a proof-of-concept APIaaS prototype based on a

service-oriented approach. In our vision, the APIaaS

layer is a PaaS layer which provides all the tools for

facilitating API composition, in particular by abstract-

ing communication protocols and message formats.

Service-oriented orchestration programming could be

adopted as a programming reference for abstracting

technological details and focusing on composition.

In § 2 we enhance the PhotoBlog example in or-

der to list all the problems related on API compo-

sition. In § 3 we list all the features of an APIaaS

layer should provide, whereas in § 4 we present our

proof-of-concept APIaaS prototype which exploits a

service-oriented approach both for the programming

and the architectural level. Finally, in § 5 we discuss

some related work, drawing our conclusions in § 6.

2 PROBLEMS WITH API

COMPOSITION

In this section we list and discuss the main difﬁculties

related to the development of applications that use and

publish APIs. We extend the example of PhotoBlog,

assuming T the technology selected for its implemen-

tation.

Documentation. Documentation regards the retrieval

and integration of documents that describe APIs for

the given technology T . In our example such a step

must be performed for the three composed APIs,

namely image, translation and blogging. Usually the

documentation is described for RESTful JSON mes-

sages so, for each service, the developer has ﬁrst to

check the documentation in order to extract infor-

mation on the identiﬁer, the type, and the semantics

of the values of request-response operations (if any).

Then the documentation of speciﬁc libraries for T

must be analysed, when supplied.

This process alone can take an important amount

of time (Erl, 2004) when compared to that one of the

development. Moreover, when the documentation is

partial or missing the developer could end in a time-

costly trial-and-error phase to acquire the information

on how to interact with an API.

Interoperability. Interoperability concerns the mech-

anisms and technologies needed for requesting ser-

vices and exchanging data between different APIs.

In our example let us suppose that T natively sup-

ports interoperability with the translation and blog-

ging APIs, but needs speciﬁc libraries for interacting

with the image one. In this situation the developer

faces two scenarios:

1. Including Libraries. The developer integrates li-

braries of T which offer ready-to-use functional-

ities and reduce the workload of the developer.

CLOSER2014-4thInternationalConferenceonCloudComputingandServicesScience

426

However library inclusion causes the following

drawbacks:

• strong dependencies in the project. Once in-

cluded, dependencies need to be kept up-to-

date and changes between versions may lead to

major changes in the implementation of the ap-

plications;

• conﬂicts among libraries, source of bugs and

unwanted side-effects;

• limited knowledge of the internal mechanisms

of libraries. This constitutes a “grey area” of

the project on which the developer has little to

no knowledge, adding complexity to the debug-

ging process.

2. Ad-hoc Solutions. The developer could spend a

signiﬁcant amount of time in implementing ad-

hoc solutions to support interoperability with the

image API in T . In this case, she would need a

comprehensive knowledge on the communication

and serialisation protocols employed by the image

API.

Publication. Published APIs allow interaction with

client interfaces and other server-side applications.

Publication concerns both APIs deployment and doc-

umentation, which represent two concerns:

• the problems addressed for interoperability hold

also for API deployment. High levels of interop-

erability bring strong dependencies on several li-

braries, whilst supporting only a few protocols re-

duces the cost of implementation to the detriment

of interoperability;

• publishing an API requires also the publication

of its companion documentation. Such documen-

tation is produced ad-hoc and requires a steady

commitment as it must be up-to-date wrt the im-

plementation it describes.

Security. Security regards secure transition, storage,

and retrieval of data and it is a major issue of any

application available on any open network. Imple-

menting and administrating security requires speciﬁc

knowledge, experience, and skills. Indeed the devel-

oper can easily include in T cryptographic libraries

for secure communication like TSL and SSL and

encryption/decryption libraries for data storage/re-

trieval. However security still requires a tremendous

effort to ensure a speciﬁc level of reliability: a devel-

oper that chooses to implement and deploy the secu-

rity of data on its own must be aware of the latest best

practices (McGraw, 2004) in security. Moreover, she

must invest a lot of effort to check the chain of com-

ponents that handle sensible data to prevent security

exploits (Barber, 2001).

In our example, PhotoBlog must provide APIs that

enable users to set persistent conﬁgurations on the ser-

vice. Users have to register to the service, link one or

more blogs to their account, and identify themselves

before publishing a post. This implies two APIs con-

cerning security: registration/access of users and reg-

istration/access to blogs, depicted in Fig. 2.

User

PhotoBlog

registers

to service

Blog

Service

verify

access

registers

blog

authenticateauthenticates

authenticates

user

<<include>>

Figure 2: Users and blogs registration.

Monitoring. After PhotoBlog has been deployed,

its administrator wants to check the performances of

her application. An important step in project develop-

ment is therefore monitoring. Monitorability (Skene

et al., 2007) is a major concern when Service-Level

Agreements (SLAs) deﬁne performances and avail-

ability of services with legal consequences such as

penalties and compensations. As for security, T prob-

ably beneﬁts from libraries to administer monitoring.

In PhotoBlog the monitoring function, provided as an

API, can serve both clients and its administrator. The

administrator can monitor the activities on its applica-

tion, checking for availability, performances, and re-

source requirements. Clients can also take advantage

of the monitoring feature to assess the availability of

the service. In addition, third parties can offer impar-

tial monitoring of services to assess compliance with

SLAs.

Portability. Portability is the degree of freedom of an

application wrt its dependencies. Internal dependen-

cies enforce the usage of libraries whose changes po-

tentially lead to major rewrites of the application. Ex-

ternal dependencies imply the presence of a speciﬁc

elements in the running environment of the applica-

tion. It could be the running environment itself, e.g.,

a speciﬁc interpreter, or other applications that must

coexist in the same platform to enable a particular be-

haviour. In the previous paragraphs we extensively

addressed the problems linked to internal dependency,

however also external dependencies are a major is-

sue which may lead to a locked-in situation. To illus-

trate this point let us say that the technology T cho-

TowardsaComposition-basedAPIaaSLayer

427

sen for PhotoBlog is Java, relying on Spring (Johnson

et al., 2005) as supporting framework. Once released

and deployed by the developer, the administrator of

PhotoBlog is forced to choose a running environment

that offers Java with Spring. In case the adminis-

trator wants to switch to another provider, she must

choose one that offers a similar running environment.

Otherwise she could spend a signiﬁcant amount of

time in setting the necessary running environment on

a generic platform i.e., installing the JVM, the Spring

framework, setting it properly, etc..

3 FEATURES OF APIaaS

In this section we discuss the basic features which

should characterize a composition-based APIaaS

layer in a cloud framework. Notably, APIs can be

divided into two groups, based on their implemen-

tation: core and composed APIs. Core APIs belong

to applications that directly implement their function-

alities without relying on external APIs (e.g., image,

translation, and blogging APIs of PhotoBlog). Com-

posed APIs derive from a behavioural composition of

other APIs like the PhotBlog API. In our perspective

an APIaaS layer should make no distinction in sup-

porting core or composed APIs.

In this work we propose an APIaaS layer as a

Platform-as-a-Service layer tailored to cope with the

issues of API composition (3b). Developers can ac-

cess such layer by means of private and secure cre-

dentials which give access to a private area that sup-

ports design of new API compositions starting from

other existing core APIs. Developers can search ex-

isting APIs in the API registry of the APIaaS layer.

APIs come with a formal interface which deﬁnes the

message types and the behaviour of the interaction.

They are also enriched with formal SLA documen-

tation which provides all the necessary information

for using/buying them. Each developer can decide to

publish her APIs as private, inner or public. Private

APIs are visible only by the author, inner APIs are

visible only within the same APIaaS platform, whilst

public APIs are visible from outside. Notably, inner

and public visibility does not imply also accessibility

and inner and public APIs can be released for free or

under payment. Deployment costs and revenues de-

pend on the business model of the APIaaS provider.

Finally each deployed API should be monitorable and

its performances visible by the administrator of the

API and its clients, guaranteeing impartial SLA con-

formance.

Coherently with this scenario we propose to di-

vide the APIaaS layer into two main sub-layers: the

Figure 3: APIaaS layer in the common cloud stack.

Abstract APIAaaS layer and the Deployment APIaaS

one, as shown in Fig.3c. The former sub-layer sup-

ports the abstract composition of APIs. The latter

provides all the necessary tools for their management.

Such a division allows to separate programming is-

sues, considered in the abstract layer, from the archi-

tectural ones, addressed by the deployment layer.

In the following, we list and discuss the main de-

sirable features for these two sub-layers.

Abstract APIaaS

• Composability: is the availability of the linguis-

tic tools that provide a suitable abstraction for

achieving composition;

• Formal documentability: is the possibility of doc-

umenting and describing each API by means of

formal and abstract interface speciﬁcations. Such

speciﬁcations can be used to achieve composi-

tion abstracting the details of real communication

protocols and message formats. Formal speciﬁ-

cations enables the automatic extraction of stubs

of descriptive documentation, thus helping devel-

opers in API documentation. In addition, semi-

automatic production of documentation uniforms

the overall documentation easing the interpreta-

tion of API documentation by clients. This feature

is currently missing in RESTful APIs where there

exist no formal nor standard language for deﬁning

API interfaces.

• Portability: deals with the possibility of moving

an API composition from an APIaaS platform to

another one without affecting its code. Porta-

bility is important to avoid lock-ins on APIaaS

providers. Lock-in avoidance is one of the key to

guarantee a competitive API market. Moreover, it

also allows to separate functionality issues from

the one related to deployment and performances.

CLOSER2014-4thInternationalConferenceonCloudComputingandServicesScience

428

Deployment APIaaS

• Protection: deals with the possibility of compos-

ing APIs within the APIaaS layer for inner us-

age, without publishing them thought a public

Software-as-a-Service layer. This feature allows

the creation of inner utility APIs used by more

complex APIs.

• Interoperability: allows the APIaaS layer to con-

nect with different applications and APIs by

supporting several communication protocols and

message formats (e.g., Http/JSON, Http/SOAP,

Java RMI, XML RPC, etc.). This feature allows to

connect the formal interfaces of the abstract layer

to concrete communication protocols and interop-

erate with external APIs.

• Publishability: deals with the possibility to select

and publish a subset of the developed APIs on the

public SaaS layer. Such feature allows mashups

and applications commonly developed with other

technologies to employ the developed APIs.

• Measurability: concerns the possibility to mea-

sure the performances of APIs in terms of re-

sponse time, memory usage, served sessions per

time unit, etc.. All these information serve for the

deﬁnition of SLA contracts both between APIaaS

providers and API developers and between API

developers and their clients. Since APIs can be in-

ternally composed, it should be possible to derive

minimal SLAs starting from the composition of

the SLAs of the composed APIs. As an example

consider the case described in § 2. Let us suppose

that the image blurring process takes at maximum

500msec whilst the process of image posting takes

at maximum 200msec. Provided these data, a de-

veloper can guarantee in PhotoBlog’s SLA that

the response time of its image posting API has a

upper bound of 700msec.

• Sandboxing: relates to the protection feature and

extends it. In particular sandboxing of code en-

ables each developer to access a different environ-

ment which runs and contains all her code. In the

sandboxing environment the developer deﬁnes the

visibility of its compositions i.e., which should be

visible internally or which have public visibility

for external usage.

• Security: deals with different aspects of security

of the APIaaS framework, i.e., : i) access secu-

rity; ii) private data consistency; iii) malware pre-

vention. Access security deals with well-known

security issues like authentication and access to-

ken release to allow clients access APIs; private

data consistency deals with issues related to cor-

ruption of private data performed by malicious ac-

tivities from the outside (e.g., hacking attacks that

alter private data); malware prevention deals with

issues related to malicious behaviour of the de-

ployed composed APIs.

• Scalability: deals with the possibility to scale the

APIaaS architecture depending on the number of

subscribed developers and the number of devel-

oped APIs.

• Federability: deals with the possibility of federat-

ing different APIaaS layers in order to share the

inner developed APIs among different providers.

Such a feature allows for the creation of a hori-

zontal layer among different cloud infrastructures

and provides the abstraction of a unique and com-

mon development framework for APIs. Such fed-

eration could be useful for the creation of groups

of specialised APIaaS providers which maximise

variety, efﬁciency, and security of offered APIs.

As an example, let us consider the case of a Smart

City that providers the federation of three differ-

ent APIaaS to citizens and companies: the mu-

nicipality APIaaS, the main hospital APIaaS, and

the public transportation company APIaaS. In this

case, developers can easily access one of the three

APIaaS and immediately exploit also all the APIs

offered by the other two with the ease, efﬁciency,

and security of the inner composition.

4 A COMPOSITION-BASED

APIaaS PROTOTYPE

In this section we describe our composition-based

APIaaS prototype, called JSOA, which is built follow-

ing a service-oriented paradigm. The prototype rep-

resents an important enhancement wrt the PaaSSOA

project (Guidi et al., 2012). In particular, JSOA intro-

duces formal documentability, a web GUI designer,

monitoring enhancements, publishability, and a pro-

totype of the SaaS layer.

4.1 Abstract APIaaS

In the Abstract APIaaS layer we follow service or-

chestration principles to supply a composition lan-

guage for APIs. In particular we use Jolie (Jolie,

2013) as orchestration language because it combines

all the basic mechanisms of the well-known web

services standards WSDL (W3C, 2001) and WS-

BPEL (OASIS, 2007) in the same linguistic domain.

In the following we discuss how composability, for-

mal documentability, and portability are achieved by

the JSOA Abstract APIaaS layer.

TowardsaComposition-basedAPIaaSLayer

429

1 main {

2 s e t I n t o B l o g ( r ) ( p ) {

3 g e t I m g W i t h F a c e B l u r@

4 ImageAPI ( r . i mag e ) ( s . image )

5 |

6 g e t E n g T r a n s l a t i o n@

7 T r a n s l a t i o n A P I ( r . t e x t ) ( s . t e x t ) ;

8 s . us er n ame = r . u s er n am e ;

9 s . pa s s w or d = r . p a s swo r d ;

10 s e t P o s t@BlogAPI ( s ) ( p )

11 }

12 }

Listing 1: Composition behaviour of PhotoBlog 2 in Jolie.

Composability. JSOA addresses composability in a

natural way using the linguistic primitives supplied

by an orchestration language (e.g., Jolie) which easily

permit to coordinate concurrent service calls, thus fo-

cusing the value on composition and not on other as-

pects of programming. In particular these primitives

cover the following aspects: i) workﬂow behaviour:

the behaviour is expressed in terms of a workﬂow

that provides both sequence and parallel operators,

therefore no thread programming is required; ii) syn-

chronous invocation primitive: APIs can be invoked

by exploiting blocking request-response primitives

which can be easily composed within the behaviour;

iii) statefulness primitives: orchestration languages

provide speciﬁc language primitives for addressing

statefulness, e.g., such as correlation sets (Mauro

et al., 2011) which ease session and state handling

at application level; iv) process spawn: process

spawn is automatically managed by the orchestra-

tion engines, no linguistic primitives are required;

v) endpoint abstraction: endpoints allows to invoke

APIs abstracting away from communication proto-

cols and message formats. List. 1 reports a snip-

pet of code corresponding to the behavioural com-

position of PhotoBlog in § 2. Notably, List. 1 does

not report the declaration part which we excluded

for reasons of presentation. In List. 1 we sup-

pose that getImgWithFaceBlur@ImageAPI (Lines 3-

4), getEngTranslation@TranslationAPI (Lines 6-

7), and setPost (Line 10) are the names of the API

for the image application, the translation application,

and PhotoBlog respectively. Moreover, we deﬁne

the name of the new composed API as setIntoBlog

(Line 2). When the API is invoked (Line 2), the layer

spawns an instance of its behaviour, executing it. In

particular List. 1 composes the image and translation

APIs in parallel (Line 5) and when they both return a

response it commands the sequential execution of the

subsequent instructions (Lines 8-9).

Figure 4: The JSOA Architecture.

Formal Documentability. In Jolie, each input and

output endpoints of a service is joined with an inter-

face which deﬁnes all the available APIs for the given

port and the message types

. Each Jolie interface can

be enriched with comments and automatically trans-

formed into an human-readable HTML document.

Portability. Portability differs if considered within

the same technology or across different technologies.

In the former case, JSOA Abstract APIaaS layer com-

pletely cope with portability issues. Since the Jolie in-

terpreter is the same, compositions developed into the

APIaaS can seamlessly execute without any signiﬁ-

cant modiﬁcation of the code (except for endpoint re-

binding which consists in a mere url location renam-

ing) on any environment that provides said interpreter.

On the contrary, in the latter case, portability is not

directly achieved but since Jolie has been developed

upon a formal semantics (Guidi et al., 2006) ad-hoc

encoding translators can be developed.

4.2 Deployment APIaaS

Fig. 4 reports a sketch of the architecture of JSOA

which implements the Deployment APIaaS layer. The

main components are:

• SOABoot: the basic component which enables ser-

vice execution in the cloud. It must be available

in each computational resource provided by the

IaaS and it takes the form of a service itself. SOA-

Boot provides three main functionalities: (i) local

Here we do not report the syntax of Jolie interfaces.

The interested reader may refer to (Jolie, 2013)

CLOSER2014-4thInternationalConferenceonCloudComputingandServicesScience

430

service registration; (ii) local service monitor logs

storage; (iii) local service execution.

• PaaSSOA: the component in charge of providing

the PaaS abstraction to the developer. It equips

a central registry that lists all running orchestra-

tors in any SOABoot available. Registered or-

chestrators can be exploited for creating new ser-

vice APIs. Moreover PaaSSOA manages a cen-

tral monitoring service which collects all the logs

from the running services.

• WSOA: the component that provides the SaaS ab-

straction and that is in charge of publishing ser-

vice APIs outside JSOA.

At the present, JSOA does not respect all the fea-

tures discussed in § 3. In the following, we brieﬂy

discuss the implemented ones whilst we address the

missing ones in § 6 as future work.

Protection. is inherently provided by JSOA since

all deployed orchestrators and core APIs can be easily

invoked by new API compositions within the Abstract

APIaaS layer.

Interoperability. is addressed by managing the de-

ployment of the Jolie endpoints depending on the re-

quired protocols. Jolie provides both input and out-

put endpoints used by an orchestrator to receive and

send messages. As a test, we developed two core

API wrappers that invoke WordReference (WordRef-

erence, 2013) and CKAN APIs (CKAN, 2013).

Publishability. is implemented by the WSOA com-

ponent which allows to select a set of already de-

ployed APIs and to export them under different proto-

cols (e.g., Http/JSON, Http/SOAP, Http/POST/XML,

etc.). As a test, we developed a plugin that enables

the composition of already published APIs within the

editor of the SATIN project (Satin, 2013).

Measurability. is provided by the monitoring archi-

tecture. A built-in monitor is attached to each de-

ployed orchestrator. The monitor sends all the logged

events to the SOABoot local monitor. In turn SOA-

Boot local monitors send collected local data to the

central monitor which stores them. The monitor-

ing architecture also provides analysis of data via the

Drools engine (Drools, 2013). The current implemen-

tation monitors start and end of sessions and start and

end of operations. Although simple these data allows

for the calculation of important statistics like API re-

sponse time, memory usage, etc..

Scalability. is addressed by SOABoot and the reg-

istry architecture. Depending on the load of the avail-

able computational resources new SOABoots can be

added. In the same way, computational resources can

be released when the corresponding SOABoots do not

execute any orchestrator.

5 RELATED WORK

Recently the communities behind the main languages

used for web development like JavaScript, Ruby, Java,

and PHP produced several RESTful (Richardson and

Ruby, 2007) libraries to ease the task of designing,

writing, and composing RESTful APIs (some exam-

ples are, respectively, (Backbone.js, 2013), (Ruby on

Rails, 2013), (Java Community Process, 2013), and

(Lavarel, 2013)). RESTful frameworks ease the de-

velopment of server-side API composition and de-

ployment yet the implementation is part of the basic

core of an application which translates into high costs

of creation and maintenance.

An inspiring work in the direction of a PaaS

middleware for application deployment is (Wettinger

et al., 2013) where the authors address the problem of

composition (and dependencies) with a middleware-

oriented approach. In particular, we notice the focus

on decoupling the application logic from the neces-

sary middleware and infrastructure resources. On the

same topic, other two interesting works are (Caporus-

cio et al., 2010; Caporuscio et al., 2014) where the au-

thors introduce the concept of a middleware to lever-

age integration of heterogeneous services for ubiqui-

tous networking. Such middleware is designed and

implemented following a service-oriented approach

supporting, respectively, SOAP and RESTful Ser-

vices. This ﬂexible and dynamic vision is also pro-

posed in (Caporuscio et al., 2011) in which third-

party applications discovered at run time should be

integrated in applications to offer more sophisticated

functionalities.

6 CONCLUSIONS

In this paper we discussed a new proposal for an

composition-based APIaaS layer which facilitates

API programming and deployment on the cloud by

enabling API composition. In our perspective the

APIaaS providers should supply large repositories of

core APIs which developers could compose. Com-

posed APIs could be available on the same reposi-

tory of core APIs, enabling the publication of new

TowardsaComposition-basedAPIaaSLayer

431

and more sophisticated services, thus fostering a liq-

uid market for APIs and the reuse of services.

We also discuss a list of basic features which

should be supported by an APIaaS layer and present a

proof-of-concept prototype, dubbed JSOA, which im-

plements a subset of such features. We based JSOA

on a service-oriented paradigm and exploited primi-

tives offered by its implementation language (Jolie) to

orchestrate APIs and, more in general, to implement

said features.

The aim of this work is to start a critical discussion

towards a shared deﬁnition of the concepts and the

foundational architecture of an open APIaaS layer.

Future Work. We intend to continue the develop-

ment of our prototype. Our experience with JSOA

proved that prototyping constitutes a relevant resource

for testing and analysing beneﬁts and drawbacks of

our approach. Namely, the next steps of JSOA de-

velopment count the implementation of features like

sandboxing, security, and federability.

In addition, we also plan to analyse how different

economic models affect a federated market of APIaaS

providers (as represented in the example regarding the

federability feature in § 3). What we expect is that

the features of our composition-based APIaaS layer

would avoid technology lock-in, lower dependencies

on speciﬁc technologies, and enact a beneﬁcial com-

petition among different providers.

REFERENCES

Backbone.js (2013). Backbone.js javascript framework.

http://backbonejs.org/.

Barber, R. (2001). Hacking techniques: The tools that hack-

ers use, and how they are evolving to become more

sophisticated. Computer Fraud & Security, (3):9–12.

Caporuscio, M., Funaro, M., and Ghezzi, C. (2011). Rest-

ful service architectures for pervasive networking en-

vironments. In Wilde, E. and Pautasso, C., editors,

REST: From Research to Practice, pages 401–422.

Springer New York.

Caporuscio, M., Funaro, M., Ghezzi, C., and Issarny, V.

(2014). ubirest: A restful service-oriented middleware

for ubiquitous networking. In Advanced Web Services,

pages 475–500. Springer.

Caporuscio, M., Raverdy, P.-G., and Issarny, V. (2010).

ubiSOAP: A Service Oriented Middleware for Ubiq-

uitous Networking. IEEE Transactions on Services

Computing.

CKAN (2013). Comprehensive knowledge archive net-

work. http://ckan.org/.

Drools (2013). Drools - the business logic integration plat-

form. http://www.jboss.org/drools/.

Erl, T. (2004). Service-Oriented Architecture: A Field

Guide to Integrating XML and Web Services. Prentice

Hall PTR, Upper Saddle River, NJ, USA.

Guidi, C., Anedda, P., and Vardanega, T. (2012). Paassoa:

An open paas architecture for service oriented appli-

cations. In ESOCC 2012, pages 208–209. Springer.

Guidi, C., Lucchi, R., Gorrieri, R., Busi, N., and Zavattaro,

G. (2006). Sock: A calculus for service oriented com-

puting. In ICSOC 2006, pages 327–338.

Java Community Process (2013). The java api for restful

web services. https://jcp.org/en/jsr/detail?id=339.

Johnson, R., Hoeller, J., Arendsen, A., Risberg, T., and

Kopylenko, D. (2005). Professional Java Develop-

ment with the Spring Framework. Wrox Press Ltd.,

Birmingham, UK, UK.

Jolie (2013). Java Orchestration Language Interpreter En-

gine. http://www.jolie-lang.org.

Lavarel (2013). The lavarel php framework. http://

laravel.com/.

Liu, X., Hui, Y., Sun, W., and Liang, H. (2007). Towards

service composition based on mashup. In Services,

2007 IEEE Congress on, pages 332–339. IEEE.

Mauro, J., Gabbrielli, M., Guidi, C., and Montesi, F.

(2011). An efﬁcient management of correlation sets

with broadcast. In COORDINATION, pages 80–94.

Springer.

McGraw, G. (2004). Software security. Security Privacy,

IEEE, 2(2):80–83.

OASIS (2007). Web services business process execu-

tion language version 2.0. http://docs.oasis-open.org/

wsbpel/2.0/wsbpel-v2.0.html.

Richardson, L. and Ruby, S. (2007). Restful Web Services.

O’Reilly, ﬁrst edition.

Ruby on Rails (2013). Ruby on rails. http://

rubyonrails.org/.

Satin (2013). Satin project. http://www.satinproject.eu/.

Skene, J., Place, M., and Crampton, J. (2007). The moni-

torability of service-level agreements for application-

service provision. In WOSP ’07, pages 3–14. ACM

Press.

W3C (2001). Web service deﬁnition language (wsdl) 1.1.

http://www.w3.org/TR/wsdl.

Wettinger, J., Andrikopoulos, V., Strauch, S., and Leymann,

F. (2013). Enabling dynamic deployment of cloud ap-

plications using a modular and extensible paas envi-

ronment. In IEEE CLOUD, pages 478–485. IEEE.

WordReference (2013). Wordreference. http://

www.wordreference.com/.

CLOSER2014-4thInternationalConferenceonCloudComputingandServicesScience

432