An application programming interface (API) is a specification intended to be used as an interface by software components to communicate with each other. An API may include specifications for routines, data structures, object classes, and variables. Open Cloud APIs are currently a heavily sought after solution to interconnect cloud applications in a more fluid manner. It also affords collaborative services between cloud service and deployment models for interoperability and data portability.
The primary mechanism for building cloud computing solutions is the APIs provided by cloud providers. The Cloud Computing Use Case states that cloud APIs work at four different levels, and they fall into five basic categories.
Levels of APIs
There are four different levels of APIs. Each level requires the developer to focus on different tasks and data structures.
Level 1 – The Wire: At this level, the developer writes directly to the wire format of the request. If the service is REST-based, the developer creates the appropriate HTTP headers, creates the payload for the request, and opens an HTTP connection to the service. The REST service returns data with an accompanying HTTP response code. Because of the straightforward nature of many REST services, it is possible to be relatively efficient while writing code at this level.
If the service is SOAP-based, the developer creates the SOAP envelope, adds the appropriate SOAP headers, and fills the body of the SOAP envelope with the data payload. The SOAP service responds with a SOAP envelope that contains the results of the request. Working with SOAP services requires parsing the XML content of the envelopes; for that reason, most SOAP services are invoked with a higher-level API.
Level 2 – Language-Specific Toolkits: Developers at this level use a language- specific toolkit to work with SOAP or REST requests. Although developers are still focused on the format and structure of the data going across the wire, many of the details (handling response codes and calculating signatures, for example) are handled by the toolkit.
Level 3 – Service-Specific Toolkits: The developer uses a higher-level toolkit to work with a particular service. Working at this level, the developer is able to focus on business objects and business processes. A developer can be far more productive when focusing on the data and processes that matter to the organization instead of focusing on the wire protocol.
Level 4 – Service-Neutral Toolkits: This is the highest level of API. A developer working at this level uses a common interface to multiple cloud computing providers. As with Level 3, the developer focuses on business objects and business processes. Unlike Level 3, a developer working at Level 4 does not have to worry about which cloud service they are working with. An application written with a service-neutral toolkit should be able to use a different cloud vendor with minimal changes to the code, if any.
Categories of APIs
Programming interfaces can be divided into five categories:
Category 1 – Ordinary Programming: The usual application programming interfaces in C#, PHP, Java, etc. There is nothing cloud-specific in this category.
Category 2 – Deployment: Programming interfaces to deploy applications to the cloud. In addition to any cloud-specific packaging technologies, this includes traditional packaging mechanisms such as .Net assemblies and EAR/WAR files.
Category 3 – Cloud Services: Programming interfaces that work with cloud services. As discussed in the previous section, cloud service APIs can be either service-specific or service-neutral. These APIs are divided into subcategories for cloud storage services, cloud databases, cloud message queues, and other cloud services. A developer writing code using cloud services APIs is aware that they are using the cloud.
Category 4 – Image and Infrastructure Management: Programming interfaces to manage virtual machine images and infrastructure details. APIs for images support uploading, deploying starting, stopping, restarting, and deleting images. Infrastructure management APIs control details such as firewalls, node management, network management and load balancing.
Category 5 – Internal Interfaces: Programming interfaces for the internal interfaces between the different parts of a cloud infrastructure. These are the APIs you would use if you wanted to change vendors for the storage layer in your cloud architecture.
A good example of the development of open specifications and APIs for cloud offerings are those being developed by Open Cloud Computing Interface (OCCI).
The Open Cloud Computing Interface comprises a set of open community-lead specifications delivered through the Open Grid Forum. OCCI is a protocol and API for all kinds of management tasks. OCCI was originally initiated to create a remote management API for IaaS model based services, allowing for the development of interoperable tools for common tasks including deployment, autonomic scaling and monitoring. It has since evolved into a flexible API with a strong focus on integration, portability, interoperability and innovation while still offering a high degree of extensibility. The current release of the Open Cloud Computing Interface is suitable to serve many other models in addition to IaaS, including PaaS and SaaS.
The Open Cloud Computing Interface is a boundary protocol and API that acts as a service front-end to a provider’s internal management framework.The next diagram shows OCCI’s place in a ’s architecture.
The Open Cloud Computing Interface began in March 2009 and was initially led by co-chairs from SUN Microsystems, RabbitMQ and Universidad Computense de Madrid. Today, the working group has over 250 members and includes numerous individuals, industry and academic parties. The OCCI community works in a distributed, open community under the umbrella of the Open Grid Forum (OGF), using a wiki and a mailing list for collaboration. The governance model ensures rights for every voice through the OCCI working group as an open body. Anyone can join and participate freely.
In my final post of the series we will look at some of the use case scenarios.
