2012 9th International Conference on Electrical Engineering, Computing Science and Automatic Control

Mexico City, Mexico. September 26-28, 2012

UML Model of a standard API for cloud computing application development

Miguel Felipe Pérez Escalera and Miguel Ángel León Chávez

Computer Science Faculty, BUAP, Puebla, Mexico
Phone (52) 222-2295500 ext. 7213 Fax (52) 222-2295672 E-mail: [email protected]

Cloud APIs are software libraries with a set of procedures,

Abstract—This paper proposes a model of a standard functions and objects that allow application developers both to
application programming interface (API) for common services access and to control the cloud platform and its resources.
used by cloud applications. It aims to homogenize the These tools are essential in order to get full access to the cloud
development over clouds in order to ease portability. The model advantages. The APIs are developed in a particular language,
includes the analysis, design and implementation using the
been the most common Java, Python and C#.
Unified Modeling Language (UML). The paper discusses also
quality criteria for its evaluation. Many clouds offer similar services like persistent storage
and database management, among others. A developer
Keywords —API, cloud, development, model, services, accesses the cloud services through the API given by the cloud
standard. provider. But each cloud is different and so are the APIs. This
is a major problem for cloud application development [3].
I. INTRODUCTION When an application is created over a cloud, using the
provided API, it falls into a concept called lock-in where the
C loud computing is a recent trend of application
development on the Web. It gives users the possibility to
deploy software systems without carrying about physical
application is tied to the infrastructure where it was created.
This is undesirable for the developer, as he will have problems
when trying to transport the application from one cloud to
infrastructure by leasing equipment over a cloud. another due to incompatibilities between APIs.
A cloud is presented to the user as a computing Some efforts have been done in order to solve this problem
environment, accessed through the Internet, with apparent in the cloud APIs. However none of the proposals have been
infinite hardware resources. adopted as an International Standard, and on the other hand
Clouds are large data centers owned by specific companies the cloud providers do not want to lose their clients.
who make them available to public through a Pay-as-you-go This paper proposes an abstract model of a standard API,
schema. Most of them use the concept of virtualization for which provides cloud application developers a set of common
both giving access to the user and offering flexible virtual services in order to access the public cloud API of their
hardware configurations [1]. choice.
Some of today’s most popular public clouds are: Google - The Standard API is developed using the Unified Software
AppEngine; Amazon – EC2; IBM – Blue cloud; and Microsoft Development Process [5] and its Unified Modeling Language.
– Azure. The rest of the paper is organized as follows: section II
Each provider organizes its cloud in a different way. But discusses some efforts in order to standardize the cloud API
there is certain basic architecture composed of layers in which services; section III presents the proposal; section IV shows
they fit [2], as Fig. 1 shows. Each layer can be seen as a part the problem trough an example. Section V presents the
of the cloud and also as a service. analysis model of the proposed Standard API; section VI
presents the design model; in section VI we implement the
The upper layer is Software as a Service (SaaS), which is
API for two clouds; section VIII verifies the functionality of
the one visible to the final user and involves applications.
the API in a example of a real application and in section IX a
The next layer is Platform as a Service (PaaS) and it matters quality evaluation for the API is included; finally some
to software developers. It is composed by the operating conclusions and future research work are discussed.
systems, application programming interfaces (API),
documentation, and basic services. II. STANDARDIZATION OF THE CLOUDS
Infrastructure as a Service (IaaS) refers to the usage of
As the cloud computing trend grows, some standards have
available resources on the cloud: memory, processors, storage,
been proposed for different entries.
etc. Finally, Hardware as a Service (HaaS) involves physical
One of them is the Open Virtualization Format (OVF) [6],
resources such as servers, racks, routers, etc.
which involves homogenizing the structure of virtual
machines to permit their transportation between clouds with
no concern of the hypervisor provider.
Another standard is proposed by the Open Clouds Standards
Incubator [7]. In the Interoperable Clouds publication they
attack the problems of interoperability between clouds. They
propose that cloud providers should incorporate standardized
Fig. 1. Layers in the architecture of a cloud
services for interconnection. The Open Grid Forum [8] also
suggests standards for interoperability among clouds.

IEEE Catalog Number: CFP12827-CDR

ISBN: 978-1-4673-2168-6 263
978-1-4673-2169-3/12/$31.00 ©2012 IEEE
 2012 9th International Conference on Electrical Engineering, Computing Science and Automatic Control
Mexico City, Mexico. September 26-28, 2012

The Open Cloud Manifesto [9] promotes that cloud A possible solution could be to standardize a set of common
implementations must use standard guidelines but it does not services offered by clouds. These services homogenize the
propose a concrete solution. interaction among APIs and define an abstract standard API.
On the other hand, jClouds [4] is a Java implementation of a Then this API needs to be implemented by each cloud
standard package to unify multiple cloud providers. It supports provider, giving access to its particular infrastructure in a
the most popular clouds and gives developers the possibility to general way. The application developer uses the standard API
keep their applications lock-in free. This might be the best without knowing how it works or caring about which cloud
approach to the proposal of this document, but its strategy is made the implementation. When she/he wants to migrate an
different. application from a cloud to another, she/he just changes the
jClouds is a nonstandard API placed between the API implementation and, maybe, a minor adjustment in the
application and the cloud’s API. Its publishers have the task to code to have it working again, as Fig. 2 shows.
incorporate support for each popular cloud. Due to this, Some clouds offer unique services that cannot be
jClouds has a potential growth problem: as more clouds standardize. This is a potential dependency between the cloud
emerge, the API gets bigger and bigger until it becomes too and the hosted application. It may always be a problem but
heavy or it has to ignore some clouds to stay light. And since using a standard API instead of the today provided will narrow
there is no commitment from clouds to jClouds, a provider it to minimum.
could change its API and affect the results of this library.
jClouds is the only way to create portable applications at the III. PROPOSAL
moment. It is a good strategy but might not be enough for the To ease portability of applications between clouds, this paper
incoming future. proposes a model of a standard API which offers a set of
Keeping aside the clouds, standard APIs are a strong and common cloud services to application developers. This is just
elegant solution to unify functionality of technology with an abstract library to be used as a template. Opposite to
multiple implementations. Let us take Java and databases. jClouds, this is not an extra tool that aims to attack the
There is a standard API known as Java Database Connectivity problem by creating a large third party API that supports many
(JDBC), which allows Java developers to interact with clouds. The purpose is to create a model that cloud providers
different database providers (Oracle, MS SQL, MySQL, etc.). follow when they develop their public APIs, naturally causing
It does not handle the real communication between the the homogenization.
application and the database; it only contains basic classes and
interfaces to define the behavior of standard objects without IV. JUSTIFICATION
implementing them. The developer includes a driver with the
adequate implementation of JDBC for the desired database As a justification, a comparative experiment was realized
manager. This gives the developer freedom to migrate from between two cloud providers to verify how the same task
one database to another by changing the driver and slightly cannot be achieved in the same way in both of them.
adjusting the code. JDBC has been the solution for databases Amazon EC2 and Google AppEngine clouds where used for
with Java for many years and it is a good example of what a the example.
well-planned standard API is.
Among public clouds the difference of APIs can be huge. The goals for this example are the following:
Let’s take Google’s AppEngine and Amazon’s EC2. The first 1. To create a text file with the name series1000.txt with
one is Web container oriented, while the second is desktop the numbers from 0 to 999 as content.
oriented. This makes too complicated to transport an 2. To store the file persistently in both clouds under a
application from one of them to the other. A work around directory named example.
could be installing a web container on the EC2 cloud to have a 3. To retrieve the file again and read its contents.
similar approach in both of them. But that is not enough; the
difference between the AppEngine API and the other one A. Example implementation
remains and the dependency of the application to it forces the Each one of the used clouds brings a development kit to
developer to adjust the original application code to the new access and control their resource. The storage schema is
cloud. The higher the dependency, the harder is to port an similar but its treatment is not. Since there were some conflicts
application. with the latest Java version 1.7, we decided to work with JDK
6 (Java 1.6).
There are two kinds of storage. The first one is local in the
Amazon’s AMI which works the same way and with the same
limitations of a regular computer. The second one is the elastic
storage which is one of the virtues of cloud computing. It is a
way of storing files in units known as buckets without
knowing where they are physically or even if they are in the
same place. Also to store with no concern about free space.

Fig. 2. Application deployed in multiple clouds using the standard API

IEEE Catalog Number: CFP12827-CDR

ISBN: 978-1-4673-2168-6 264
978-1-4673-2169-3/12/$31.00 ©2012 IEEE
 2012 9th International Conference on Electrical Engineering, Computing Science and Automatic Control
Mexico City, Mexico. September 26-28, 2012

Fig. 3. Code comparison to create a text file with EC2 and AppEngine. Left: Code for EC2 using conventional storage. Middle: Code for
AppEngine. Right: Code for EC2 using elastic storage.

A. Amazon EC2 implementation B. Google AppEngine implementation

Amazon EC2 gives the possibility to use virtual machines Google’s cloud is used trough a Web container developed
that simulates the behavior of a complete real computer with by the same provider. There is no concept of virtual machines.
some familiar operative systems (Windows and Linux It does not have a conventional storage service either. The
versions) called AMIs (Amazon Micro Instance). In this storage service is elastic just like S3, but this time the file is
demonstration a Linux Amazon EC2 micro instance is used. created trough a petition to the service and the content is
This AMI has 8 Gb of conventional storage. It also supports written directly to the file by opening a channel
elastic storage. The example was done with both storage (FileWriteChannel) which has to be closed twice: one to end
variations. the streaming and another to make the file read only. The
development of the example required the use of Google’s API:
Conventional storage implementation AppEngine SDK 1.6.4.
Thanks to virtualization, it was possible to access the Linux Trough a Servlet, the file with the desired content was
native file system and the example’s task was done using basic created. Another Servlet was implemented to load the contents
Java tools included in the java.io package. A local file was again. This was successful.
created under the required directory and the content was
written to it using a conventional FileOutputStream. C. Source code comparison
The result was the correct execution of the implemented The source code of each of the implemented classes is show
code; the file was created correctly through a Servlet and in this comparison for all used platforms.
loaded back with no problems with a second Servlet. The conflicting code segments that prevent portability are
highlighted with squares. The solid lines marks the code to
S3 elastic storage implementation needed to create the file, while the dashed lines shows the
Amazon also supports elastic storage which is called S3 code lines used to write the content to the file. Fig. 3 shows
(Simple Storage Service). In S3 is possible to use in the name the source code for each of the classes.
of the file a whole hierarchic path which simulates the use of Finally we observe the header of the file loading classes of
directories. This part of the example required the use of the the third step of the experiment. It is clearly appreciated the
API given by Amazon: AWS SDK 1.3.7 code dependency to the particular clouds.
To generate the files it was necessary to first create it in the The proposal in this paper attempts to release the classes
local system using java.io and uploaded to the bucket later used in cloud computing from this dependency, allowing them
trough a file uploading request PutObjectRequest. to be easily ported from one platform to the other. Fig. 4
Also the load of the file was successful and shorter as S3 shows the imported classes and packages of the classes
allows opening a direct connection (InputStream) to the file in implemented for EC2, AppEngine and a prototype of what
the bucket and read its contents. would be the header of a provider-free implementation would
To access the bucket in the cloud the application requires be.
some authentication trough credentials since the services can D. Example’s results
be used outside of the Amazon infrastructure. In Table 1 we present technical data of the way each case is
solved in the different platforms. With this, we conclude the
following:
Even that is possible to achieve all the required operations
in both clouds, the source code conflicts shows that the
adjustment in a migration would be significant and expensive.
Alarming is the imports situation in the source codes which
are dependent to the providers API and won’t work with
another one.
It is clear that there is no compatibility among these two
cloud providers and it is not easy to port applications between
them.
Fig. 4. Imports of the classes to load the file content

IEEE Catalog Number: CFP12827-CDR

ISBN: 978-1-4673-2168-6 265
978-1-4673-2169-3/12/$31.00 ©2012 IEEE
 2012 9th International Conference on Electrical Engineering, Computing Science and Automatic Control
Mexico City, Mexico. September 26-28, 2012

TABLE 1.
TECHNICAL COMPARISON FOR THE THREE IMPLEMENTATIONS.
Case   Amazon  local   AppEngine   Amazon  S3  

Create  a  file  instance   The class File from java.io is An AppEngineFile instance is acquired by requesting A local file must be created and after is
used, which is well known in the creation in the bucket to the service. uploaded to the bucket.
Java development.

Write  content  to  the   The text is written directly by A FileWriteChannel which is opened from an existent A local file is written in the same way as
file   opening a FileOutputStream to instance of the file in the bucket. Then a regular in the local case. Then the file is
the local file. stream must be opened. uploaded to the bucket.

Read  the  content  of   A FileInputStream is opened to A FileReadChannel to the file in the bucket must be A direct InputStream to the file in the
the  file   the file directly and the text can requested to the service and then we can open a bucket is requested.
be read. regular input stream.

V. ANALYSIS MODEL OF THE STANDARD API • User management service: the front end of many
The goal of this paper is to propose the basic structure of a software systems on the cloud is presented as a web
standard API for cloud computing by following the Unified application and user accounts are basic on this
Software Development Process methodology and using the paradigm. The cloud provider implements
Unified Modeling Language. In order to do this, we begin by registration and login procedures releasing the
identifying the common services provided by clouds. Here, a application developer of these tasks. The developer
service is a set of tools and protocols offered to the user in accesses a limited set of information about already
order to solve a particular problem and meet its requirements. created user accounts and relies on the cloud’s
This paper proposes eight services as an attempt to group security.
the most general needs of a web application developer. • E-mail access service: since there are user accounts, an
e-mail system is also useful to communicate them. In
• Quota service: allows the application to know the
this case, the cloud hosts e-mail servers to be used by
status of the resources quota established on the
the applications and the user itself.
leasing plan. With this service the application can
• Data processing service: needed to take advantage of
react when maximum quota is being reached or
the unlimited resources of a cloud when processing
exceeded.
complex information or large amounts of data. Here
• Persistent storage service: to save and load
the cloud provider implements cooperative
information with a traditional file schema in
distributed oriented systems (like Map-Reduce) to be
nonvolatile storage devices. The duty of the cloud
used by the developer.
provider is to have a distributed enlargeable file
The implementation of these services will not be easy for all
system accessed and managed by the cloud user
cloud providers. But this is a worthy effort as we will have
through the service. Includes access rules,
better compatibility and gives an added value to cloud users.
permissions, and isolation.
• Database management service: to access and manage A. Use cases diagram
relational databases. In this case, the cloud provider An actor is an entity that interacts within the system by
must offer a way of working with apparent unlimited giving or requesting services to another, as Fig. 5 shows. In
relational databases even if they work with other this case, two actors of the Standard API are identified:
designs. • The application developer is who requests services to
• Security service: to establish secure communication the cloud. It builds applications using the tools given
channels between a cloud application and the final by the cloud provider.
user or another application. Also to protect sensitive
information through encryption algorithms and
signatures. The cloud provider implements a set of
common security algorithms or includes a third-party
library.
• Communication service: to transfer data from one
application to another inside or outside the same
cloud. Now the cloud provider implements protocols
to open, use, and close data flows between
applications. It may also give a set of standard data
types known by other clouds.

Fig. 5. Cases diagram of the standard API services

IEEE Catalog Number: CFP12827-CDR

ISBN: 978-1-4673-2168-6 266
978-1-4673-2169-3/12/$31.00 ©2012 IEEE
 2012 9th International Conference on Electrical Engineering, Computing Science and Automatic Control
Mexico City, Mexico. September 26-28, 2012

VI. DESIGN MODEL OF THE STANDARD API

This model is composed of several diagrams, such as
classes, interaction, sequence, collaboration, activities, and
state. This section only presents the class diagram of one
service, the persistent storage service; the section presents also
some sequence diagrams.
A. Persistent storage service class diagram
The class diagrams define all the attributes and methods
required to implement the services. Fig. 7 shows the class
diagram of the persistent storage service, it can be noted that
Fig. 6. First approach of the class diagram
shaded classes and interfaces are those related to the service.
CloudServiceException contains methods to find out the
• The public API is the set of tools presented to the type and cause of an error and below it the error classes
developer as a black box. It implements the real related to the storage service.
interaction with the cloud provider. PersistentStorageService interface offers a way to access
and modify a file system, either physical or virtual. With it,
B. Class diagrams the developer can list the system roots (if more than one
In the analysis model the class diagram models the service exists), query in its application the available free and used
implementation with no detail but presenting the organization space by giving a persistent object as reference, create and
of the classes and packages. Fig.6 shows this diagram. manipulate persistent files and directories and open data
The Standard API is presented as a class but only to group streams to persistent files. This class includes methods to
the classes and interfaces of the system cover operations to query the status of the service, if it is
The Platform package represents the real implementation supported by the cloud, if developer has access to the service
of the API that each public cloud provides. Its contents does and finally to manage the service.
not concern to the model as each provider is allowed to Notice that developer’s access to each service is quite
implement by his very own way. important, since the cloud may offer different access schemes
The CloudService interface is the abstraction of every according to the leasing plan. These methods should be
service provided by the cloud. Each particular service extends common to all services.
from this interface. PersistentFSObject interface describes an object that is
CloudServiceException class is the parent of all cloud errors stored in the file system. This object could be a File (which
thrown by the API’s services. It aims to illustrate how the API has data content), Directory (file grouping) or Root (root
includes utility entities to be wide enough. directory of the file system). This interface allows to query
The rest of the interfaces match each one of the eight basic information about the object, such as: name, path, creation and
services shown in the use cases diagram. modification timestamps, permissions (UNIX style), attributes
(masking bits of an integer) and about its existence.

Fig. 7. Persistent storage service classes diagram

IEEE Catalog Number: CFP12827-CDR

ISBN: 978-1-4673-2168-6 267
978-1-4673-2169-3/12/$31.00 ©2012 IEEE
 2012 9th International Conference on Electrical Engineering, Computing Science and Automatic Control
Mexico City, Mexico. September 26-28, 2012

A. SPIs and connectors

The API being designed is the skeleton o a complete library.
The abstract part does not contain the code that actually
handles the resources. Mostly is formed by abstract classes
and methods which require an implementation from the cloud
provider. This side of the API is known as the SPI (Service
Provider Interface). Once the provider removes the abstraction
by implementing the missing functionality, the API is ready to
be release to application developers and we will call this a
connector.
Just to illustrate how the API works and to evaluate its
quality, two connectors are implemented: one for EC2 and the
other for AppEngine. It is worth mentioning that the
implementations are purely experimental since the real cloud’s
connectors generation will happen once the model is taken as
Fig. 8. Sequence diagram of the interaction with a service. a standard and the providers implements their own.
B. Sequence diagram B. Connectors for EC2 and AppEngine
There must be a protocol for developers in order to use a By applying a layer over the Amazon’s development kit
service. The sequence diagram of Fig. 8 shows how any (AWS SDK 1.3.7) a connector is created to remove the
service could be invoked by calling methods in each service abstraction of the standard API. Internally the methods do the
interface. With this interaction the developer is confident that necessary invocations to the Amazon’s functions. In the same
the service will be available when the application needs it or way we work with the AppEngine SDK 1.6.4. In Fig. 11 a
react if it does not. sequence diagram is included and we can appreciate the task
The sequence diagram shown in Fig. 9 is included to implemented in the Google’s connector when an invocation to
illustrate the process followed by the application developer to write content to a file is done.
achieve a particular task (in this case, to create a persistent file
in the file system). Other processes are not included to keep VIII. API USAGE IN A REAL EXAMPLE
this document compact.
To verify the functionality of the designed API and validate
that it really eases portability, a practical real example was
VII. API IMPLEMENTATION
developed. The example consists in a Java Web application
Using the design model we implemented the standard API in to manage files in the cloud. This file manager allows the user
its abstract version, the one that does not really implement the to create and delete files and directories; rename, copy and
services and it just presents interfaces and abstract classes that move files; write and read text to a file trough a familiar
shape the services. graphic user interface.
The implementation walks together with the design model The example generation with the AppEngine’s connector
and some classes are added and reorganized with the goal of took about 1170 lines of code (including HTML). To migrate
making the API more complete. to Amazon, by changing the connector, only 5 lines of the
In Fig. 10 is presented the implementation’s resulting classes whole code where adjusted. This represents a 0.4%, which is
hierarchy desirable. It can be noted in Fig. 12 the only code variations
required.

Fig. 9. Sequence diagram for the persistent storage service

IEEE Catalog Number: CFP12827-CDR
ISBN: 978-1-4673-2168-6 268
978-1-4673-2169-3/12/$31.00 ©2012 IEEE
 2012 9th International Conference on Electrical Engineering, Computing Science and Automatic Control
Mexico City, Mexico. September 26-28, 2012

In the case of the cloud computing standard API, the class

diagram presents those entities visible to users. As this the
first version, it defines the API signature.

B. API’s evolution plan

Software system users will always seek more than they
have and APIs are not the exception. If an API has the
potential to grow in versions after its first release, it is
important to plan this growth. We should try to foreseen its
natural evolution from what we design at the beginning. To
accomplish this, we must include an evolution plan that
indicates how to include new functionality and modules to
make a new version of the API without losing compatibility
with previous versions.
Fig. 10. Standard abstract API’s classes hierarchy
C. Evaluating the standard API
By being clever, these modifications could be Six topics to verify the quality of the API will be introduced
parameterized avoiding any need to touch the source code. next by making an analysis of what we have designed. By
This experiment shows that the API fulfills its purpose using the implemented connectors for Google and Amazon we
properly. can validate the SPI and use the file manager example to
evaluate the whole API.
IX. QUALITY EVALUATION OF THE API
The expected result in this project is an API which eases API organization for different audiences: the API being
cloud application development. To achieve this, it is quite designed in this paper has characteristics of both API and SPI;
important to design it with quality. therefore the evaluation should be done from the two
An API is software and its development process is similar perspectives:
to any other software system. But since it aims developers and From those who use the programmers interface: this is the
not final users, APIs specific criteria must be evaluated. This point of view of a programmer who takes the API as a black
will not be entirely easy as some aspects are too abstract and box and uses its services to create an application in the cloud.
subjective. Here we will talk about the API.
An API must be elegant and atractive at plain sight. These From those who implements the providers interface: it is the
to draw users attention and interest from the beginning. vision that a cloud provider has when creating a library,
Atractive meaning that the API should be clear and simple, according to its platform, that removes the abstraction of the
without loosing completeness. Elegant by keeping simple standard API by implementing methods, classes and missing
procedures easy. But this two topics are just the beginning of procedures. Here we will talk about the SPI.
the evaluation. Some other topics should be taken into account Both points of view (the SPI and API) cause, in a natural
as the folloings [10]: way, a division of the library. A well organized API avoids
users to get confused. All services offered by the SPI must be
A. The API – User contract implemented by the cloud providers. At the same time, those
services must give access to the user trough the API.
The public part of the API (those methods, classes and
attributes the user can access and use) is known as the method Completeness: To the user, the standard API satisfies the
and field signature. This signature is a contract generated basic expected needs, it should do it correctly too, but it is too
between the API and its users from its very first release. If the soon to evaluate this topic as there is no real implementation.
signature changes, the programs where users implemented the To the cloud provider, the SPI gives enough flexibility to
API may stop working. integrate its services. We remark the following:
This affects directly the maintenance stage of the API, • The classes to implement are public and not final.
where it is very important to respect this contract. • Covers all use cases of the implemented service.
• The functions to manage services are public.
• Contains utility objects that requires no
implementation.
• Uses flexible parameterization on service instantiation.
• Each service is modeled in a separated class to avoid
conflicts between them; this also allows new services
to be included in the future.

IEEE Catalog Number: CFP12827-CDR

Fig. 11. Sequence diagram when opening a write stream to a file in Google’s 269
ISBN: 978-1-4673-2168-6
cloud connector
978-1-4673-2169-3/12/$31.00 ©2012 IEEE
 2012 9th International Conference on Electrical Engineering, Computing Science and Automatic Control
Mexico City, Mexico. September 26-28, 2012

future. Re-work an application due to an external component

will cause the developer to search for better and more
consistent tools.
This topic is particularly important for the API design as the
audience is made of programming users which cannot expend
time fixing their applications every time the API changes. On
the other hand, if the SPI contract causes the cloud providers
to adjust their libraries they will have periods with high
percentage of failing hosted applications.
No version has been released therefore is too soon to evaluate
this topic.

X. CONCLUSION
It is clear that cloud computing will continue growing and it
is important to have guidelines and standards to avoid anarchy
Fig. 12. Code variations to work with Google and Amazon’s clouds
on application development.
This paper has discussed the problematic caused by the lack
of standard application programming interfaces in the clouds.
Comprehensibility: If the API user or the SPI implementer
By identifying common services based on development
does not understand it, perhaps the target user’s knowledge
needs, a standard API was proposed and modeled using the
was not correctly evaluated. There must be an estimation of
Unified Software Development Process methodology and
the average profile required. Concerning about this means that
UML.
the API should be really easy to understand without losing
This proposal attempts to be the beginning of a complete
neither completeness nor performance. The desired user’s
model for a standard API to be implemented.
profile for the standard API is a medium level Java developer.
It is not necessary to have advanced knowledge to exploit its
functionality.
To the SPI implementer, a clear package will be given; REFERENCES
about what it is supposed to be done and how. A [1] M. A. Vouk, “Cloud Computing – Issues, Research and
Implementation”, Journal of Computing and Information Technology –
misunderstanding could result in unpredictable results. These eCIT, vol. 16, no. 4, pp. 235-246, 2008.
are some evaluation results: [2] B. P. Rimal, E. Choi, and I. Lumb, “A Taxonomy and Survey of Cloud
• Uses clear terminology and code conventions [11] Computing Systems”, in Proc. of Fifth International Joint Conference
• Is written in English on INC, IMS and IDC. pp. 44-51, 2009.
[3] B. Claybrook. “Weighing the cloud computing standards dilemma”, in
• Requires no advanced programming skills Search Cloud Computing. Feb 2011. Available at:
• Class and method’s names are descriptive. http://searchcloudcomputing.techtarget.com/feature/Weighing-the-
cloud-computing-standards-dilemma
Consistency: The consistency of an API embraces from [4] jClouds. Available at: http://code.google.com/p/jclouds/
[5] I. Jacobson, G. Booch, and J. Rumbaugh. “Unified Software
entity naming up to release versions. Development Process”. Ed. Addison Wesley, 1999.
Data types chosen for certain cases, are being used [6] Distributed Management Task Force (DMTF): Open Virtualization
wherever the application is the same, so the user can Format specification. Available at: http://www.dmtf.
remember them easily and predict what methods will use even org/standards/published_documents/ DSP0243_1.0.0.pdf.
[7] Distributed Management Task Force (DMTF): Open Cloud Standards
if they are unknown for him. Incubator. Available at: http://www.dmtf.org/ about/cloud-incubator.
The contract between the API and the user was mentioned [8] Open Grid Forum (OGF): Open Cloud Computing Interface
before. This must prevail trough the evolution of the system; Specification, Open Cloud Computing Interface Working Group,
provide backwards compatibility without contradict neither Available at: http://www.occi-wg.org.
[9] Open Cloud Manifesto. Available at:
structure nor functionality. http://www.opencloudmanifesto.org/Open%20Cloud%20Manifesto.pdf
[10] J. Tulach, “Practical API Design: Confessions of a Java Framework
Exhibit: the exhibit refers to the facility the API gives to the Architect”, Ed. Apress. EUA, 2008.
user to understand it and learn it. In both sides (API and SPI) [11] Java Code Conventions. Available at:
http://www.oracle.com/technetwork/java/codeconventions-150003.pdf
there must be clear and complete information about how to
use the system. These are some results in the evaluation of
exhibit:
• The abstract API includes inline documentation
(Javadoc).
• The developed UML model can be used as reference.
• Processes documentation is not done yet.

Preserve user’s investment: A developer invests time and

effort when creating an application and, if this uses a third
party API, it needs this investment not to be wasted in the

IEEE Catalog Number: CFP12827-CDR

ISBN: 978-1-4673-2168-6 270
978-1-4673-2169-3/12/$31.00 ©2012 IEEE