Evolution of the Open Cloud Computing Interface

Boris Par

, Zden

Sustr

, Michal Kimle

, Pablo Orviz Fern

andez

Alvaro L

opez Garc

ıa

Stavros Sachtouris

and V

ıctor M

endez Mu

noz

Department of Distributed Computing, CESNET z.s.p.o, Zikova 4, Prague, Czech Republic

Instituto de F

ısica de Cantabria (CSIC-UC), Avda. de los Castros s/n, Santander, Spain

Greek Research & Technology Network, Mesogion Av. 56/11527, Athens, Greece

Computer Architecture & Operating Systems Department, Universitat Aut

onoma de Barcelona, Bellaterra, Spain

Keywords:

Cloud, Standards, Architecture, Interoperability, Management, OCCI.

Abstract:

The OCCI standard has been in use for half a decade, with multiple server-side and client-side implemen-

tations in use across the world in heterogeneous cloud environments. The real-world experience uncovered

certain peculiarities or even deﬁciencies which had to be addressed either with workarounds, agreements be-

tween implementers, or with updates to the standard. This article sums up implementers’ experience with the

standard, evaluating its maturity and discussing in detail some of the issues arising during development and

use of OCCI-compliant interfaces. It shows how particular issues were tackled at different levels, and what

the motivation was for some of the most recent changes introduced in the OCCI 1.2 speciﬁcation.

1 INTRODUCTION

The Open Cloud Computing Interface (OCCI) is a

RESTful protocol and API for a variety of manage-

ment tasks. OCCI was originally designed to cre-

ate a remote management API for IaaS (Infrastruc-

ture as a Service) model-based services, allowing

for the development of inter-operable tools for com-

mon tasks including deployment, autonomous scal-

ing, and monitoring of virtual machines and related

resources (Metsch and Edmonds, 2011b).

Since its publication in April 2011, OCCI has

been adopted by a variety of cloud, cloud-like and

cloud-adjacent platforms as the interoperability in-

terface of choice. The strength of OCCI lies in its

well though out and rather abstract core speciﬁca-

tion (Nyr

en et al., 2011) resembling more a mod-

eling language than a communication protocol. It

gives OCCI its extensibility and wide-range applica-

bility. Every other part of OCCI builds on top of

the core speciﬁcation by proposing various extensions

targeting speciﬁc areas such as infrastructure manage-

ment, monitoring, accounting, over-the-wire render-

ing, transport protocol, billing, and many others.

The OCCI standard speciﬁcation currently (in ver-

sion 1.1) consists of three separately published docu-

ments:

1. GFD.183 – OCCI Core

(Nyr

en et al., 2011)

2. GFD.184 – OCCI Infrastructure

(Metsch and Edmonds, 2011b)

3. GFD.185 – OCCI HTTP Rendering

(Metsch and Edmonds, 2011a)

However, the abstract and minimalistic nature of

OCCI has its disadvantages. Most notably, signiﬁ-

cant parts of the standard require careful interpreta-

tion when creating a real-world implementation. This

often leads to incompatibilities between implemen-

tations provided by different developers. This paper

is an attempt to brieﬂy introduce popular implemen-

tations of OCCI (Section 2), collect as much feed-

back from their developers as possible, describe most

commonly encountered issues based on the aforemen-

tioned feedback (Section 3), and propose solutions

wherever possible either by referencing the upcoming

OCCI 1.2 standard (a set of not yet published docu-

ments, which have been, however, made available for

public comment during 2015) or by suggesting future

improvements (Section 4). Finally, Section 5 makes

an overall statement on the suitability and maturity of

OCCI as it stands today.

Parák, B., Šustr, Z., Kimle, M., Fernández, P., García, Á., Sachtouris, S. and Muñoz, V.

Evolution of the Open Cloud Computing Interface.

In Proceedings of the 6th International Conference on Cloud Computing and Services Science (CLOSER 2016) - Volume 2, pages 339-346

ISBN: 978-989-758-182-3

339

2 IMPLEMENTATIONS

Over the last ﬁve years, OCCI gained multiple experi-

mental and production-grade implementations in vari-

ous states of usability. These implementations helped

the overall evolution of the standard and contributed

to the work being done by the OGF OCCI Working

Group on the OCCI 1.2 standard. The following sec-

tions brieﬂy describe the most prominent or widely

used open-source OCCI implementations whilst also

mentioning particular development challenges. This

list is by no means all-encompassing; it is meant to

provide a quick overview. The implementations listed

here are also closely related to EGI and EGI Federated

Cloud (del Castillo et al., 2015) due to existing afﬁli-

ations of involved authors. Other prominent projects

and implementations of OCCI not mentioned in this

section include OCCIware (OCCIware Consortium,

2016), erocci (Parpaillon, 2016), and pyssf (Metsch,

2016). Readers are hereby encouraged to explore

these as well.

2.1 The rOCCI Framework

The rOCCI framework, originally developed by

GWDG, later adopted and now maintained by CES-

NET, was written to simplify implementation of the

OCCI 1.1 protocol in Ruby and later provided the

base for working client and server components giving

OCCI support to multiple cloud platforms while en-

suring interoperability with other existing implemen-

tations (Par

ak et al., 2014).

At the time of writing this paper, the rOCCI

framework has two published components:

rOCCI-core and rOCCI-api. These serve as

the base for two end-user products: rOCCI-cli and

rOCCI-server.

The initial server-side component provided basic

functionality and served as a proof of concept when it

was adopted by the EGI Federated Cloud Task Force

and was chosen to act as the designated virtual ma-

chine management interface (Wallom et al., 2015).

This led to further funding from the EGI-InSPIRE

project, development of a full featured client and a

new rOCCI-server suitable for production environ-

ment.

rOCCI-core is a central component of the frame-

work. It implements classes representing entities de-

ﬁned by the OCCI standard, provides parsing and

rendering capabilities to/from multiple message for-

mats. Currently supported, as both input and output

formats, are plain-text and JSON which is based on

an early draft of OCCI 1.2 JSON rendering (not yet

published). It also introduces various helper classes

such as Collection or Model, simplifying the han-

dling and rendering of complex OCCI messages, pro-

vides advanced logging and attribute validation facil-

ities. Using Ruby’s meta-programming techniques,

the core is able to “extend itself” with new classes and

deﬁnitions provided dynamically at run-time. This

works well with OCCI’s inherent extensibility.

rOCCI-api builds on top of rOCCI-core and im-

plements support for transport protocols and corre-

sponding authentication methods. It also provides an

extended set of various helpers simplifying the use of

rOCCI-core and targeting the development of client-

side applications and tools. HTTP (Fielding and Get-

tys, 2014) is currently the only supported transport

protocol.

rOCCI-api also implements a pluggable authen-

tication mechanism capable of fall-backs. Every au-

thentication plug-in can declare a set of alternatives

to be used in case of failure. This concept is capable

of masking differences between various cloud frame-

works implementing OCCI using their own authenti-

cation schemes.

rOCCI-cli, built on top of rOCCI-api, serves

as an end-user client providing a shell-based in-

terface. It allows users to interact with OCCI-

compliant interfaces and perform basic operations

and actions. Similarly, rOCCI-server, built on top of

rOCCI-core, provides a server-side implementation

supporting multiple cloud management frameworks

or public cloud providers as its back-ends, expos-

ing their resources via an OCCI-compliant interface.

It currently supports OpenNebula (The OpenNebula

Project, 2016) and Amazon Web Services EC2 (Ama-

zon Web Services, Inc., 2016), with plans to imple-

ment support for Microsoft Azure (Microsoft, 2016).

The most notable challenges encountered whilst

implementing parts of the rOCCI framework were, in

no particular order, the plain-text rendering, the lack

of clear authentication guidelines, missing parts of

the attribute model, and vague (side-)effect descrip-

tions for the infrastructure extension. The following

paragraphs will brieﬂy address each of these issues in

greater detail.

Implementing a plain-text-based rendering of a

non-trivial protocol is always a challenge. The un-

structured nature of a plain text requires customized

regular expressions or state machines for extract-

ing relevant information. It also prevents the devel-

oper from using existing well-tested parsers or seri-

alization and de-serialization libraries. Writing cus-

tomized parsers is always time-consuming and prone

to errors, which are difﬁcult to discover.

The lack of clear authentication guidelines is a

feature of the OCCI standard. It simply points the

OCCI 2016 - Special Session on Experiences with OCCI

340

reader to mechanisms appropriate (and standardized)

for the given transport protocol, which helps to keep

the standard extensible. However, it makes the im-

plementation of working OCCI-enabled components

difﬁcult, especially in a heterogeneous environment

where a certain level of interoperability is desirable.

This forces developers to implement complex fall-

back or discovery mechanisms, with wildly varying

levels of success.

Parts of the OCCI standard, especially the core

speciﬁcation, are rather abstract and the mechanisms

described therein are difﬁcult to implement. Develop-

ers are often left to their own devices, which leads to

further discrepancies in interpretation between imple-

mentations. One such part is the attribute model, lack-

ing detailed description and implementation guide-

lines.

Last but not least, effects or side-effects of particu-

lar operations or actions deﬁned in various extensions

of the OCCI standard often have vague descriptions.

This makes aligning the behavior of implementations

across multiple platforms very difﬁcult. A uniﬁed be-

havior is a strong requirement for the user.

2.2 The jOCCI Framework

The jOCCI framework is a set of Java libraries im-

plementing the OCCI standard. jOCCI currently con-

sists of two client-side components, jOCCI-core and

jOCCI-api, which together create a communication

layer for OCCI clients and servers alike (Kimle et al.,

2015).

jOCCI-core covers basic OCCI class hierarchy

from both OCCI Core and OCCI Infrastructure and

relations between them. Furthermore, jOCCI-core

provides methods for parsing and rendering plain-text

representations of OCCI classes. This functionality

is crucial for transporting data between the client and

the remote server via HTTP messages. In addition,

jOCCI-core also validates any OCCI request with re-

spect to the declared OCCI model. This helps identify

requests that would be rejected by server, even before

they are sent.

jOCCI-api is a Java library implementing the

transport layer functionality for rendered OCCI ob-

jects and queries. It is built on top of jOCCI-core and

currently provides only HTTP transport functionality

with a set of authentication methods and basic inter-

faces to simplify client-server communication.

The jOCCI library stack is currently used in the

jsaga-adaptor-jocci (Rocca, 2016) project de-

veloped primarily for the Catania Science Gateway

Framework (Fargetta, 2016). The aim of this project

is to develop JSAGA (Reynaud and Schwarz, 2016)

adaptor which will expose an interface for submitting

grid jobs into automatically provisioned virtual ma-

chines in OCCI-compliant clouds. Another project

utilizing jOCCI as the cloud-facing backend is the

Karamel (Hakimzadeh, 2016) orchestration frame-

work, heavily used in the bio-informatics commu-

nity (Bessani et al., 2015). The so-called OCCI

“launcher” adds support for the provisioning of on-

demand virtual machines in OCCI-compliant clouds.

The Karamel OCCI launcher is currently being devel-

oped and tested at CESNET.

As mentioned before, jOCCI is written in the Java

programming language. This language was selected

because of its popularity and demand by the commu-

nity. Since Java is a strongly typed language, some of

the concepts of the OCCI standard (e.g., mixins) were

somewhat challenging to implement. Nevertheless,

jOCCI’s API was designed to meet the requirements

of the OCCI standard whilst keeping Java’s best prac-

tices in mind. For details, see Figure 1.

jOCCI currently implements version 1.1 of the

OCCI standard. During the development of the li-

braries the authors encountered multiple caveats in

this version of the standard. One of the problems is

that the speciﬁcation does not clearly state which at-

tributes are internal and which should be available in

rendering. Another problem comes from the plain text

rendering, which is lacking the expressive power of

other standard formats such as XML or JSON, mak-

ing it difﬁcult to render complex data structures.

Both jOCCI-core and jOCCI-api are distributed

via Maven Central Repository utilizing well-known

dependency management practices common in the

Java developers community.

2.3 OpenStack OCCI Interface

ooi (L

opez Garc

ıa et al., 2016) is an implementation

of OCCI for the OpenStack Compute project, written

entirely in Python so as to make exhaustive usage and

proﬁt from the already available OpenStack modules,

such as authentication. ooi was designed to be easily

integrated with the OpenStack core components, but

with the aim of being independent from any Open-

Stack version or release.

The main motivation for this recent development

stems from the need to overcome key architectural de-

sign issues found in the previous OCCI implemen-

tation, OCCI-OS (Metsch et al., 2016), namely the

fact of using the internal OpenStack APIs directly.

In contrast with the public APIs, the private ones are

not versioned and are subject to change at any time

in the development cycle, even between minor re-

leases. Instead, ooi interacts with OpenStack lever-

Evolution of the Open Cloud Computing Interface

341

HTTP client

Authentication

Methods

●

BASIC

●

DIGEST

●

X.509

●

VOMS

●

Keystone

Parser

OCCI Core Classes

OCCI Infrastructure Classes

JOCCI-api

jOCCI libraries

JOCCI-core

OCCI

Server

jOCCI

Client

Figure 1: jOCCI-* architecture overview.

aging its public APIs to process any incoming OCCI

request, translating it forth and rendering it back to

get a proper and valid OCCI response. Unlike OCCI-

OS, ooi has been designed as a WSGI middleware

embedded in the OpenStack pipeline, located prior to

the public API request processing and, accordingly,

appearing as the ﬁrst step once the API returns the

response object.

At the time of writing this paper, ooi supports the

OpenStack API version 2.1, but additionally it can be

deployed on top of the previous and backwards com-

patible API version 2.0. Moreover, ooi allows the co-

existence of isolated environments in terms of multi-

ple OCCI endpoints mapped to different OpenStack

API versions in the same installation, making it pos-

sible for providers to deploy several OCCI versions

in different endpoints using the same deployment. In

this regard, the current version of ooi implements

version 1.1 of the OCCI standard, but the aforemen-

tioned design would make it possible to deploy sev-

eral OCCI versions using the same installation.

The most relevant challenge faced when develop-

ing ooi was the implementation of text rendering for

such a complex protocol. The parsing of plain-text

structures representing more complex structures has

been also identiﬁed as one of the major drawbacks

in the other OCCI implementations, such as rOCCI

(Section 2.1) and jOCCI (Section 2.2). In this re-

gard, the adoption of JSON rendering in version 1.2

of the standard would be a step forward when com-

OpenNebula Master Node

Apache HTTP Server

Phusion Passenger

rOCCI-server

OpenNebula

Backend

rOCCI

OCCI

compliant

clients

mod_ssl

Figure 2: rOCCI-server in a typical setup with the Open-

Nebula Cloud Manager.

pared with OCCI 1.1.

Since its release, ooi has been adopted in the EGI

Federated Cloud as the reference implementation for

the OpenStack providers.

2.4 OpenNebula OCCI Interface

As mentioned in Section 2.1, rOCCI-server acts

as an OCCI-compliant interface for OpenNebula. It

has been designed as a stateless proxy translating

OCCI messages to native API calls for OpenNebula.

Its main purpose is to hide platform-speciﬁc behav-

ior from the user and create the illusion of a seam-

less OCCI-compliant service across multiple hetero-

geneous cloud platforms. As rOCCI-server is built

on top of rOCCI-core, discussed in greater detail in

Section 2.1, further description of its OCCI-related in-

ternals is omitted here.

For detailed description of rOCCI-server’s archi-

tecture and deployment, see Figure 2.

2.5 Synnefo OCCI Interface

The Synnefo OCCI interface (Athanasia Asiki, 2014)

acts as an API middleware between the OCCI pro-

tocol and the Synnefo API (synnefo.org, 2015).

Synnefo cloud software (synnefo.org, 2014) utilizes

Ganeti (Guido Trotter, 2013) as a low-level virtualiza-

tion layer to provide compute and storage cloud over

OCCI 2016 - Special Session on Experiences with OCCI

342

an extended OpenStack API. The ˜okeanos IaaS (Van-

gelis Koukis, 2013), which provides compute and

storage resources to the Greek and European aca-

demic communities, is the largest Synnefo deploy-

ment.

Synnefo (open source IaaS software) and

˜okeanos (IaaS service powered by Synnefo) are

maintained and provided by the Greek Research

and Technology Network (GRNET), which is the

National Research and Education Network (NREN)

provider of Greece. The principal role of GRNET is

to operate the Greek Academic network, connect it

with global academic communities and institutions,

and provide them with cutting edge IT services and

technology. GRNET is a key national level facilitator

in the ﬁelds of distributed and large-scale research

infrastructures including Grid, Cloud and HPC. It

coordinates the Greek National Grid Initiative –

HellasGrid and is a member of the EGI pan-european

grid infrastructure.

The Synnefo OCCI interface features a distributed

design of separate components (e.g., snf-occi and

astakos-vo-proxy) which are connected via REST-

ful APIs. The rationale behind the aforementioned

design choice is to ensure adaptability to the evolution

of both OCCI and Synnefo, as well as robustness and

security through the deployment on isolated nodes.

The main component of the interface is called

snf-occi, a service that maps OCCI v1.1 requests

to OpenStack/Synnefo. It is designed to run as a

stand-alone service, connected to Synnefo through

its RESTful API. Incoming (OCCI) requests are val-

idated syntactically and corresponding users are au-

thenticated. Synnefo credentials are retrieved through

an API call to the astakos-vo-proxy component.

The credentials are attached as headers to requests to

the Synnefo API. Results are then reverse-mapped to

be OCCI-compliant and returned as the response to

the initial request.

astakos-vo-proxy acts as a user mapping agent

with user creation and modiﬁcation capabilities. As-

takos is the authentication and policy (e.g., user

quota) enforcement component of Synnefo. To facil-

itate the mapping between OCCI and Synnefo users,

the proxy maintains an LDAP directory with the min-

imum user information needed for the mapping. Pos-

sible changes in the status of the supported user pool

are reﬂected by frequently updating the directory with

the assistance of a human operator.

Authenticating OCCI users who do not exist in

the Synnefo user base was one of the most intriguing

challenges while developing the interface. To tackle

this issue, astakos-vo-proxy is equipped with the

ability to create and modify Synnefo users and their

quota policies. Every time a new but valid OCCI user

attempts to access a Synnefo cloud through the OCCI

interface, the proxy will create a new Synnefo user.

On the other hand, if the user exists, the correspond-

ing information is retrieved from the directory.

The mapping of OCCI users to Synnefo users con-

stitutes a security challenge, because it allows users

outside of the scope of a standard Synnefo deploy-

ment to be created on demand and also because it

maintains a directory of sensitive user information

and credentials. To protect astakos-vo-proxy, it

must be deployed in a trusted and isolated environ-

ment.

A stable version of the snf-occi and the

astakos-vo-proxy components are deployed for the

˜okeanos IaaS. Both components are deployed on sep-

arate virtual nodes powered by the said IaaS.

3 ISSUES

This section collects input from Section 2, ﬁnds

language-independent commonalities and draws con-

clusions on the usability of OCCI 1.1 in real-

world implementations. It aims at identifying the

most severe obstacles preventing further adoption of

the OCCI standard among developers and service

providers.

Issues outlined below were selected from Sec-

tion 2 based on the following criteria:

• impact on future standard development (1)

• number of occurrences (2)

• subjective signiﬁcance (3)

Formal Documents

The overall readability of documents formalizing the

standard is a very important factor, especially in early

stages of its adoption. In this area, a number of devel-

opers expressed concern. Speciﬁcally, the more ab-

stract parts should be explained in greater detail, with

practical examples if applicable.

In many cases, a single word has two or three

different meanings depending on the current context.

This should be avoided wherever possible by intro-

ducing new terminology or, at least, carefully aligned

across all published documents to minimize inconsis-

tencies, especially with regard to third-party exten-

sions.

Evolution of the Open Cloud Computing Interface

343

Design

With regard to the minimalistic and extension-based

design of OCCI, no major issues were reported. There

are certain interoperability challenges speciﬁc to this

particular design; however, no explicit objections

were raised by developers.

Core

In the core speciﬁcation, attribute description and dis-

covery was the most commonly reported problem. In

OCCI 1.1, attributes are not properly speciﬁed and de-

ﬁned in the context of the OCCI (meta)model. This

leads to implementation-speciﬁc solutions and differ-

ences in behavior.

In the next revision of the standard, attributes

should be clearly deﬁned in the OCCI (meta)model,

including attribute properties and validation mecha-

nisms.

Extension

When it comes to extensions, most developers

have experience only with the Infrastructure exten-

sion. In this extension, vague descriptions of var-

ious operations and actions on resource instances

were the most frequently reported issues. When

the speciﬁcation does not provide a clear descrip-

tion of effects and side-effects, these are left to

implementation/developer-speciﬁc interpretation. It

leads to issues with interoperability.

In the next revision of the standard, additional ex-

planations and descriptions should be added wherever

possible. However, it is understood that strict guide-

lines in this area would limit further proliferation and

adoption of the standard due to platform-speciﬁc lim-

itations.

Transport

No issues were reported for transport-layer speciﬁca-

tions, currently represented only by the HTTP speciﬁ-

cation (Metsch and Edmonds, 2011a). Improvements

were suggested for the parts dealing with authenti-

cation and authorization mechanisms; however, these

are designated as “out-of-scope” by the standard.

Rendering

All reported issues were targeting the plain-text ren-

dering (Metsch and Edmonds, 2011a), being the only

currently published rendering speciﬁcation. Issues

ranged from relatively minor (parsing difﬁculties and

performance) to distinctly major ones (inability to

represent complex data types or advertise/discover

necessary endpoint information).

The overall consensus on these issues is the need

for new rendering formats with accompanying exten-

sions/speciﬁcations outlining their use, including ex-

tensive examples.

4 TOWARDS OCCI 1.2

This section aims to address recent advancements to-

wards the ﬁnal OCCI 1.2 speciﬁcation with regard to

issues outlined in Section 3. The following subsec-

tions focus on the aforementioned issues one by one.

Work on the OCCI 1.2 speciﬁcation is performed by

the OGF OCCI Working Group; this paper provides

only an overview. The following list of changes is by

no means complete.

Formal Documents

The OCCI documents underwent a signiﬁcant refac-

toring. The OCCI 1.2 standard consists of seven sep-

arate documents covering core (Nyr

en et al., 2016b),

infrastructure (Edmonds et al., 2016), HTTP proto-

col (Nyr

en et al., 2016a), text rendering (Edmonds

and Metsch, 2016), JSON rendering (Nyr

en et al.,

2016c), PaaS (Platform as a Service) (Metsch and

Mohamed, 2016), and SLAs (Service-Level Agree-

ments) (Katsaros, 2016). With the addition of one

proﬁle document (Drescher et al., 2015) attempting

to standardize available compute resource sizes. This

should greatly improve readability and decouple un-

related extension speciﬁcations. At the time of writ-

ing the paper, the ofﬁcial documents are not yet pub-

lished.

Design

No signiﬁcant changes were made to the overall de-

sign of the OCCI protocol in order to maintain good

backward compatibility with OCCI 1.1.

Core

Attribute description in the OCCI (meta)model has

been appropriately updated and OCCI 1.2 clearly de-

ﬁnes how to represent model attributes, including at-

tribute properties. This change is based on existing

implementations and should hence cover all required

use cases such as attribute discovery or attribute value

validation.

OCCI 2016 - Special Session on Experiences with OCCI

344

Extension

Information regarding the use of OS and Resource

template mixins has been updated and extended to

give deeper insight into their intended purpose. In-

consistencies in other parts of the infrastructure exten-

sion have been corrected (removed useless attributes

and unusable actions, adjusted vague wording wher-

ever possible). However, key parts of the document

outlining effects and side-effects of various actions

remain unchanged to avoid overly restricting future

implementations.

Transport

No signiﬁcant changes were made to the transport-

layer speciﬁcation, aside from major document refac-

toring which separated HTTP protocol from the plain

text rendering speciﬁcation and minor clariﬁcation re-

garding the use of HTTP status codes to relay action

results.

Rendering

To maintain backward compatibility with OCCI 1.2,

no signiﬁcant changes could be made to the plain text

rendering of OCCI. However, to address issues raised

by a number of developers, a new mandatory render-

ing was introduced as an extension – the JSON ren-

dering. Using JSON (Crockford, 2006), including an

example JSON Schema (Galiegue et al., 2013) for

OCCI messages, should greatly simplify implemen-

tation and provide much needed reliability.

5 CONCLUSION

OCCI is a well-matured and well-accepted protocol,

with a wide user base – mainly among academic

users – and a number of independent implementa-

tions. Given that its authors were always striving

for ﬂexibility, discrepancies naturally had to occur

in OCCI-compliant tools, especially in the early ver-

sions. However, the OCCI community was able to

overcome that: ﬁrstly by being able to ﬁnd common

interpretation in problem areas, and secondly by be-

ing able to keep the standard evolving, answering

not only to new needs but also to old aches of inter-

operable clouds.

ACKNOWLEDGEMENTS

In no particular order, authors would like to acknowl-

edge their home institutions: CESNET, Masaryk Uni-

versity, Instituto de F

ısica de Cantabria, GRNET, and

Universitat Aut

onoma de Barcelona. They would also

like to thank their colleagues from EGI and members

of the EGI Federated Cloud. The credit for work

on the OCCI standard and its continuous evolution

goes to Open Grid Forum and OGF’s OCCI Work-

ing Group.

This work is co-funded by the EGI-Engage project

(Horizon 2020) under Grant number 654142.

REFERENCES

Amazon Web Services, Inc. (2016). Amazon Web

Services - Elastic Compute Cloud. [Online]

https://aws.amazon.com/ec2/. Accessed: March 10,

2016.

Athanasia Asiki, C. (2014). Synnefo OCCI Interface.

[Online] https://code.grnet.gr/projects/snf-occi. Ac-

cessed: March 10, 2016.

Bessani, A., Brandt, J., Bux, M., Cogo, V., Dimitrova, L.,

Dowling, J., Gholami, A., Hakimzadeh, K., Hum-

mel, M., Ismail, M., et al. (2015). Biobankcloud: a

platform for the secure storage, sharing, and process-

ing of large biomedical data sets. the First Interna-

tional Workshop on Data Management and Analytics

for Medicine and Healthcare (DMAH 2015).

Crockford, D. (2006). The application/json Media Type for

JavaScript Object Notation (JSON). RFC 4627 (Infor-

mational).

del Castillo, E. F., Scardaci, D., and

Alvaro Lop

ez Garc

ıa

(2015). The egi federated cloud e-infrastructure. Pro-

cedia Computer Sceince, (68):196–205.

Drescher, M., Par

ak, B., and Wallom, D. (2015). OCCI

Compute Resource Templates Proﬁle rev. 2. [Online]

https://goo.gl/puR6JG.

Edmonds, A. and Metsch, T. (2016). Open Cloud Com-

puting Interface – Text Rendering rev. 1.2. [Online]

https://goo.gl/puR6JG.

Edmonds, A., Metsch, T., and Par

ak, B. (2016). Open Cloud

Computing Interface – Infrastructure rev. 1.2. [On-

line] https://goo.gl/puR6JG.

Fargetta, M. (2016). Catania Science Gateway Framework.

[Online] http://www.catania-science-gateways.it/.

Accessed: March 10, 2016.

Fielding, R. and Gettys, J. (2014). Hypertext Transfer Pro-

tocol (HTTP/1.1): Message Syntax and Routing. RFC

7230.

Galiegue, F., Zyp, K., and Court, G. (2013). Json schema:

core deﬁnitions and terminology. draft-zyp-json-

schema-04.

Guido Trotter, T. (2013). Ganeti: Cluster Virtualization

Manager. USENIX;login, (3).

Evolution of the Open Cloud Computing Interface

345

Hakimzadeh, K. (2016). karamel. [Online]

https://github.com/kamalhakim/karamel. Accessed:

March 10, 2016.

Katsaros, G. (2016). Open Cloud Computing Interface

– Service Level Argeements rev. 1.2. [Online]

https://goo.gl/puR6JG.

Kimle, M., Par

ak, B., and

Sustr, Z. (2015). jOCCI

– general-purpose OCCI client library in java. In

ISGC15, The International Symposium on Grids and

Clouds 2015. PoS.

opez Garc

ıa,

A., Fern

andez del Castillo, E., and Orviz

Fern

andez, P. (2016). ooi: OpenStack OCCI interface.

SoftwareX, (xxxx):1–6.

Metsch, T. (2016). Service sharing facility. [Online]

https://github.com/tmetsch/pyssf. Accessed: March

10, 2016.

Metsch, T. and Edmonds, A. (2011a). Open Cloud Com-

puting Interface – HTTP Rendering. GFD-P-R.185.

Metsch, T. and Edmonds, A. (2011b). Open Cloud Com-

puting Interface – Infrastructure. GFD-P-R.184.

Metsch, T., Edmonds, A., and L

opez Garc

ıa,

(2016). OCCI Interface for OpenStack. [On-

line] https://github.com/stackforge/occi-os. Accessed:

March 10, 2016.

Metsch, T. and Mohamed, M. (2016). Open Cloud

Computing Interface – Platform rev. 1.2. [Online]

https://goo.gl/puR6JG.

Microsoft (2016). Microsoft Azure: Cloud Computing

Platform. [Online] https://azure.microsoft.com/. Ac-

cessed: March 10, 2016.

Nyr

en, R., Edmonds, A., Metsch, T., and Par

ak, B. (2016a).

Open Cloud Computing Interface – HTTP Protocol

rev. 1.2. [Online] https://goo.gl/puR6JG.

Nyr

en, R., Edmonds, A., Papaspyrou, A., and Metsch, T.

(2011). Open Cloud Computing Interface – Core.

GFD-P-R.183.

Nyr

en, R., Edmonds, A., Papaspyrou, A., Metsch, T., and

Par

ak, B. (2016b). Open Cloud Computing Interface

– Core rev. 1.2. [Online] https://goo.gl/puR6JG.

Nyr

en, R., Feldhaus, F., Par

ak, B., and

Sustr, Z. (2016c).

Open Cloud Computing Interface – JSON Rendering

rev. 1.2. [Online] https://goo.gl/puR6JG.

OCCIware Consortium (2016). Occiware project. [Online]

http://goo.gl/M1rZKv. Accessed: March 10, 2016.

Par

ak, B.,

Sustr, Z., Feldhaus, F., Kasprzak, P., and Srba, M.

(2014). The rOCCI project – providing cloud interop-

erability with OCCI 1.1. In ISGC14, The International

Symposium on Grids and Clouds 2014. PoS.

Parpaillon, J. (2016). Occi compliant rest framework.

[Online] https://github.com/erocci/erocci. Accessed:

March 10, 2016.

Reynaud, S. and Schwarz, L. (2016). JSAGA. [Online]

http://software.in2p3.fr/jsaga/dev/index.html. Ac-

cessed: March 10, 2016.

Rocca, G. L. (2016). jsaga-adaptor-jocci. [On-

line] https://github.com/csgf/jsaga-adaptor-jocci. Ac-

cessed: March 10, 2016.

synnefo.org (2014). Synnefo White Paper. [Online]

https://goo.gl/LDvTsf. Accessed: March 10, 2016.

synnefo.org (2015). Synnefo API. [Online]

https://www.synnefo.org/docs/synnefo/latest/api-

guide.html. Accessed: March 10, 2016.

The OpenNebula Project (2016). OpenNebula

Cloud Management Framework. [Online]

http://www.opennebula.org/. Accessed: March

10, 2016.

Vangelis Koukis, Constantinos Venetsanopoulos, N. (2013).

okeanos: Building a Cloud, Cluster by Cluster. IEEE

Internet Computing, (3):67–71.

Wallom, D., Turilli, M., Drescher, M., Scardaci, D., and

Newhouse, S. (2015). Federating infrastructure as a

service cloud computing systems to create a uniform

e-infrastructure for research. In IEEE 11th Interna-

tional Conference on e-Science, 2015. IEEE.

OCCI 2016 - Special Session on Experiences with OCCI

346