CompatibleOne Overview

CompatibleOne is an open source project which provides a model, CORDS (CompatibleOne Resource Description System), and a platform, ACCORDS (Advanced Capabilities for CORDS), for the description and federation of different clouds comprising resources provisioned by heterogeneous cloud service providers. CompatibleOne's flexible service architecture makes it independent from any Cloud Service Provider (from OpenStack to OpenNebula, from Azure to Vcloud) and can address all types of cloud services (IaaS, PaaS, SaaS , XaaS, BpaaS, …) and any type of cloud service deployment (public, private, community and hybrid).
The goals of CompatibleOne are to:
Download CompatibleOne Open Source Broker Architecture Overview which covers the architecture and core concepts of the project  

CompatibleOne Synopsis

CORDS (CompatibleOne Resource Description System) is an Object Oriented language for the description of Cloud Applications, Services and Resources.
The CompatibleOne Platform i.e. ACCORDS (Advanced Capabilities for CORDS) is a cloud provisioning and deployment control system.
The diagram below shows the architectural vision of CompatibleOne in 4 steps:

Step 1: CompatibleOne Manifest: the consumer's needs are described in a service manifest.
Step 2: CompatibleOne Plan: the corresponding provisioning plan is built and validated.
Step 3: CompatibleOne Contract: the provisioning plan is transformed into contracts with selected providers.
Step 4: CompatibleOne Service: delivers the cloud services.

1: Taking into account user requirements

User requirements take the form of a manifest file, precisely describing the required services in terms of both technical and economical criteria. Additionally the manifest may indicate particular constraints that are to be respected . The structure of the manifest file corresponds to the model described by CORDS (CompatibleOne Resource Description System). This model is based on OCCI (Open Cloud Computing Interface).
CORDS Logical view
Click to enlarge
CORDS Service Control Graph
Click to enlarge

2: Design and construction of the plan

The manifest is received by the SLAP MASTER allocation engine. This engine triggers the gathering of events required for accounting and billing, and then transmits the manifest to the ACCORDS Parser. The ACCORDS Parser transforms the XML description of the manifest file into a validated and well-formed provisioning plan. The ACCORDS Parser performs a syntactic verification of the manifest file prior to engaging the descriptive resources used to represent the resulting architectural plan required to meet the specific requirements.

3: Execution of the provisioning plan

Once validated, the provisioning plan is transmitted to the ACCORDS Broker. The ACCORDS Broker is in charge of executing the provisioning plan for the production of an actual service instance to be delivered to the user. The broker will instantiate a service graph for the control of the contractual components described in the plan. During this operation the ACCORDS Broker will collaborate with various CompatibleOne service providers as required for the realization of the plan. This will be performed while respecting the different constraints and conditions expressly defined in the plan, such as an carrier selection, optimization, monitoring or accountancy.

4: Cloud services delivery

The ACCORDS Broker coordinates the activity of the ACCORDS Procci for the selection of the specific cloud providers for the delivery of the provisioning services required by the consumer. A particular provider's ability to deliver resources is guaranteed by their declaration of presence, and their consequently available resources, to the ACCORDS Publisher. Providers are selected by the ACCORDS Procci as directed either by the constraints described in the provisioning plan or specified in the global configuration of an operational instance of the ACCORDS platform. Communication with the Provider is performed through standard ACCORDS OCCI client/server interfaces between the ACCORDS Procci, on the CompatibleOne side, and the Provider Procci, on the Provider side. In this way a individual and specific Procci service provider is responsible for interfacing with a particular Cloud Provider, e.g. an OpenNebula Procci, an OpenStack Procci, an Amazon Procci or an Azure Procci. Consequently, in order to be made available for operation and use within ACCORDS, a resource needs only to implement an OCCI client/server Procci interface.
Communication Architecture
Click to enlarge
The example of OpenStack Nova Provisioning
Click to enlarge

The Manifests, the Plans, the Contracts and the Services are stored in the Knowledge Base are. A unique and universal identifier is attributed to each element in the Knowledge Base and may be used to reference the element for use in subsequent solutions. This can be in the definition of topologies specific to certain activities such as clouds for High Performance Computing or as an Internet Service Provider or SaaS Editor.

CompatibleOne and PaaS

The ACCORDS platform services have been designed in such a way that enables developers to use the platform of their choice to run their applications e.g. JavaEE, and not the other way round i.e. to be forced to port their applications according to specific and proprietary features of a PaaS provider such as AWS Beanstalk or Google App Engine (the paper "Interoperable and Portable Cloud Services" written by Anton Panhelainen from Aalto University School of Chemical Technology, covers nicely what are the fundamental stakes of our design).

Once the platform has been chosen and described by a CORDS manifest, the ACCORDS platform provisions it. The approach adopted by CompatibleOne for the provisioning of platform services is really quite simple. The platform itself is to be described by a CORDS manifest consequently permitting its deployment by the ACCORDS platform. A particular component of the platform known as the PaaS Procci will make itself known through ACCORDS Publisher as a provisioner of service for the deployment of nodes of its particular type. The PaaS Procci will also submit two types of manifests for parsing by the ACCORDS Parser describing on the one hand services offered by the platform to an end user (the developer and her application) and on the other hand the resources required by the PaaS for the delivery of these services. In this way, nodes representing service of type PaaS may be used indifferently in application manifests allowing seamless integration with more traditional IaaS nodes.

By extension of the PaaS technique and using interfaces exposed by their provisioned components the ACCORDS platform is available to provide symmetrical solutions that may be employed for the dynamic integration of heterogeneous components and services required for the construction of more complex service systems such as XaaS and BPaaS to name but a few.

To know more, read INTEL's Journey to Cloud  which describes CompatibleOne as next generation cloud management 

CompatibleOne Flight Plan

CompatibleOne working on Clouds the traditional road map is replaced by a Flight Plan.
In the area of broker, multi-cloud, federation, automation, etc., CompatibleOne has a broad scope of interests. This is why we designed this map which will enable to identify topics which could be of some interest for you too.

The CompatibleOne Flight Plan presentation in few slides.
A full detailed description of the CompatibleOne Flight Plan is available here.
The Flight Plan is revised on a 3 months period. If you are interested or if you have any suggestion, please do not hesitate to contact us.

NIST Reference Architecture

CompatibleOne is compliant with NIST Reference Architecture V2.
See how CompatibleOne is aligned with NIST Reference Architecture

CompatibleOne FAQ

Which interfaces for CompatibleOne?
Can CompatibleOne provision more than one cloud service?
What about the network?
Who should use CompatibleOne and Why ?
Glossary, Acronyms and Abbreviations
Which interfaces for CompatibleOne?
First it seems  all CompatibleOne components use REST to communicate. It seems that each “cloud provider” is accessed through an OCCI proxy which is then perhaps translated to the native API (e.g. OpenStack).  However the interfaces between the different CompatibleOne components (e.g. publisher, parser or broker) are so far not published on CompatibleOne's  web site. Where could we have access to these?

This understanding of the architecture is exact, the different proxy components, or proccis, in CompatibleOne jargon offer a standard OCCI interface to the generic procci for the 'negociation' of contract instances over a REST interface. The interface has not been published as such, simply because it is a standard OCCI REST interface and the usual OCCI capacity discovery mechanisms are available for clients to be able to consult the different server components with respect to their interface categories and their associated actions. Each of the interface  categories will of course be fully documented  as they reach maturity during the project. 
Can CompatibleOne provision more than one cloud service?
Is the aim of compatible one is “to be able to deploy an application across more than one cloud”, or to only deploy an application in one of the possible clouds? Either for the initial deployment or later for life cycle management (e.g. scale up). From the resource description schema, it does not seem that this is currently envisaged. But is this in the CompatibleOne roadmap?

The architecture was devised to be as flexible as possible for the description of complex cloud systems. It is intended for a wide range of uses from the simple private corporate infrastructure usage to the fully blown public infrastructure cloud broker. The differences really lie in the way the platform is configured to behave by the actual operator.  A Manifest  however may declare that a node be contractually instanced through a specific cloud provider for technical reasons, or it may be left to the broker to decide taking into consideration financial, energetic, geographic or operator contractual preferences. A complete service manifest may describe nodes provisioned by different cloud providers and being "sewn" together by the configuration section of the manifest. 
What about the network?
From the point of view of the network, this schema defines an L2 network.  OCCI model is used here. Reading the documentation, it is difficult to know if CompatibleOne will use the NetworkLink to create links (routes/firewalls) between created networks. However for now, it seems that what is supported is that a single “network” is created and the VMs/storage are deployed within that network. So is it possible to know more of CompatibleOne road map on  this item?

As far as networking goes, in the current state of the CompatibleOne platform, the aim is to provide an automatic provisioning system and would indeed appear to target a single network but in fact, in order that the provisioning may scan multiple and heterogeneous cloud provider platforms, the idea of a single network is very much ruled out since the different VM's would be within the local network space of each provisioner. In such complex cases the CompatibleOne platform aims at provision of the necessary network components, be they simple public IP addresses or more complex VPN and tunnelling configurations. Devices of this kind, including routers and firewalls are intended to be described in the same terms as othe nodes with the concerned Manifest. Symmetry is the aim here, as far as possible.
Who should use CompatibleOne and Why ?
Open cloud has a strong potential for the catalysis of new ideas and initiatives. CompatibleOne is as such a good example. By establishing the necessary foundations for the operators, developers and architects of cloud computing, CompatibleOne facilitates the creation of new services and even new professions.
Cloud Operators would be able to use CompatibleOne cloudware to maximize returns in the exploitation of their data centers in terms of economical, technical and geographical criteria. The CORDS model was designed to be usage driven and these operators could eventually define their infrastructures in accordance with their target market be they provision of internet services, hosting, on demand HPC and so on and so forth. 
A cloud entrepreneur would be able to offer, thanks to CompatibleOne, and in complete independance  with respect to the choice of actual operator, services to their clients with a high added value. It would become possible, for example, to imagine the provision of a courtier service based on diverse criteria, their professional orientation (automobile, aeronautics, defense, agriculture, …) or their economical constraints (the best cloud services or the best price offered to local government for example).
Finally, for a software developer and vendor, CompatibleOne cloudware provides the ideal tools  for the construction of new and inovative offers of highly competitive services compared to those already available. Detailled billing of service would be possible allowing examination of actual and real service consummation with an aim to optimisation of the resources required. In addition these services would be offered in form of SaaS.
Glossary, Acronyms and Abbreviations
ACCORDSAdvanced Capabilities for CORDS
COEESCompatibleOne Energy Efficiency Service
COIPSCompatibleOne Image Production Service
COMONSCompatibleOne Monitoring Service
CONETSCompatibleOne Network Service
COOBAASCompatibleOne Ordering, Billing, Accounting Service
COPSCompatibleOne Placement Service
CORDSCompatibleOne Resource Description System
COSSCompatibleOne Security Service
OCCIOpen Cloud Computing Interface Working Group


CompatibleOne Collaterals
CompatibleOne Boilerplate (May 2012)
CompatibleOne develops the first industry-grade open source cloud broker. It addresses the need for interoperability in the field of Cloud Computing. CompatibleOne is an open source collaborative project supported by 14 partners; it is open to any partner wishing to contribute efforts and tools for the building of an open cloud infrastructure based on open standards. The CompatibleOne platform fully leverages the Open Cloud Computing Interface (OCCI), it is aligned with the Cloud Computing Reference Architecture2 of the National Institute of Standards and Technology (NIST) and is part of the OW2 Open Source Cloudware initiative (OSCi).

This wiki is licensed under a Creative Commons 2.0 license
XWiki Enterprise 4.5.1 - Documentation - Legal Notice

Site maintained by