The problem with interoperability in Cloud providers is well-known. Different Cloud providers use their own and independent interface. This makes it difficult to communicate and federate multiple providers . To solve this, OCCI API has been proposed as a common standard in order to overcome this problem. OCCI is a Cloud Interaction Layer which uses HTTP methods (like GET, POST, PUT, DELETE) using XML format. This interface uses multiple data structures (i.e. Compute, Network, Storage) to describe the different resources. Using these structures, it can operate the virtual resources (i.e. create, list, show, update, delete).
The initial goal of the API OCCI is to provide an extensible interface to Cloud Infrastructure Services (IaaS). The OCCI API is a RESTful service, allowing for the development of interoperable tools for common tasks including deployment (create, control), autonomic scaling and monitoring Cloud resources.
|
This API allow for:
|
OCCI have been as modular as possible to facilitate future extension.
The core protocol is completely generic, describing how to connect to a single entry point, authenticate, search and CRUD operations (Create, Retrieve, Update and Delete resources) using existing standards including HTTP (Plain Text), TLS, Oauth, JSON and Atom/Pub. State control (start, stop, restart), billing, performance, etc. The scope of the specification will be all high level functionality required for the life-cycle management of virtual machines (or workloads) running on virtualization technologies (or containers) supporting service elasticity. Using a simplified service lifecycle model, it supports the most common life cycle states offered by Cloud providers.
Simply by standardizing at this level OCCI may well become the HTTP of Cloud Computing. There is a good article that compares OCCI API with HTML. Is OCCI the HTTP of Cloud Computing?
RESTful web services
A RESTful Web Service offers these HTTP methods: GET, PUT, POST and DELETE. OCCI API is a RESTful service and has methods associated with each resource type: Pool Resources (collection of elements owned by a given user) and Entry Resources (single entry within a given collection).
| GET | PUT | POST | DELETE | |
| Pool Resources (PR) | to list all the entry resources in that pool resource owned by the user |
x |
to create a new entry resource |
x |
| Entry Resources (ER) | to list the information associated with that resource | to update the resource (only supported by the COMPUTE resource) |
x |
to delete the resource |
XML format is used to represent COMPUTE, NETWORK and DISK resources; as well as the collection of them (Pool Resources, PRs).
POOL RESOURCE
- References a URI for the ER.
Example:
| <COMPUTES><COMPUTE href=”http://www.opennebula.org/compute/234″><COMPUTE href=”http://www.opennebula.org/compute/432″><COMPUTE href=”http://www.opennebula.org/compute/123″></COMPUTES> |
NETWORK
- ID, the uuid of the network
- NAME, describing the network
- ADDRESS, of the network
- SIZE, of the network, defaults to C
Example:
| <NETWORK><ID> 123 </ID><NAME> Blue Network </NAME><ADDRESS> 192.168.0.1 </ADDRESS> <SIZE> C </SIZE> </NETWORK> |
STORAGE
- ID, the uuid of the image
- NAME, describing the image
- SIZE, of the image in MBs
- URL, pointer to the original image
Example:
| <DISK><ID> 123 </ID><NAME> Ubuntu 10.04 </NAME> <SIZE> 2048 </SIZE> <URL> file:///images/ub untu/ubuntu.img </URL> </DISK> |
COMPUTE RESOURCE The compute element defines a virtual machine by specifying the configuration attributes. It is more complex than previous resources commented:
- ID, the uuid of the virtual machine.
- NAME, describing the virtual machine.
- TYPE, a COMPUTE type specifies a CPU and memory capacity, valid types are small, medium and large.
- STATE, the state of the COMPUTE.
- DISKS, the block devices attached to the virtual machine (DISK, SWAP, FS)
- NICS, the network interfaces, defined with a list of NIC elements. (UUID, IP…)